jc@minya.UUCP (John Chambers) (03/19/88)
Well, it happened again, and I'm getting rather curious. The .rnews
directory here got very large, and was filled with a horde of empty
files. For assorted reasons, I'd doctored the news source so that
every call of system() was surrounded by output to stderr, which I
directed to an audit file. The following was in it:
Command: "/usr/bin/rnews -S -p 5153"
Status=0.
Command: "/usr/bin/rnews -S -p 88031812151497"
Status=0.
Command: "/usr/bin/rnews -S -p 88031812151499"
Status=0.
Command: "/usr/bin/rnews -S -p 8803181215149b"
Status=0.
Command: "/usr/bin/rnews -S -p 8803181215149d"
Status=0.
Command: "/usr/bin/rnews -S -p 8803181215149f"
Status=0.
Command: "/usr/bin/rnews -S -p 880318121514a1"
Status=0.
Command: "/usr/bin/rnews -S -p 880318121514a3"
Status=0.
Command: "/usr/bin/rnews -S -p 880318121514a5"
Status=0.
Command: "/usr/bin/rnews -S -p 880318121514a7"
and so on for (according to wc) about 32000 lines, at which point everything
hung because the news partion was out of blocks. Well, it may not have been.
I unmounted it and ran fsck, and 11014 blocks re-appeared.
Anyhow, the above file names are a bit peculiar, and I've seen them before
They obviously consist of a timestamp (this happened on March 18), plus some
sort of sequence number that goes up by two. I've looked at all the calls
of open() and fopen() in the news source, and none of them look like they
create such file names, but I'm obviously missing something.
I've been considering putting in a hack to intercept all the opens, check
for this sort of name, and put out warnings. Meanwhile, I thought I'd
ask if anyone out there has any idea why these files get created. They
always seem to be empty, and they don't always stay around long (though
this time they did).
Anyone know what might be going on?
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)usenet@jclyde.UUCP (Usenet control) (03/20/88)
In article <483@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Well, it happened again, and I'm getting rather curious. The .rnews >directory here got very large, and was filled with a horde of empty >files. For assorted reasons, I'd doctored the news source so that > >Command: "/usr/bin/rnews -S -p 5153" >Status=0. >Command: "/usr/bin/rnews -S -p 88031812151497" [ more lines like the ones above deleted ] >Anyone know what might be going on? Looks to me like you have SPOOLNEWS defined in the defs.h of your news source. This directs rnews to spool all incoming to news to .rnews to be unspooled at a later date by rnews -U (which doesn't want to work here, I am at patchlevel 12 running under SCO Xenix Release 2.1.3 with the 2.1.3 development system upgraded I guess to 2.1.3UG, it allowed me to compile news :-)). -- John B. Meaders, Jr. 1114 Camino La Costa #3083, Austin, TX 78752 ATT: Voice: +1 (512) 451-5038 Data: +1 (512) 371-0550 UUCP: ...!uunet!utastro!bigtex!jclyde!john or john@jclyde
wisner@eddie.MIT.EDU (Bill Wisner) (03/21/88)
In article <605@jclyde.UUCP> usenet@jclyde.UUCP (Usenet control) writes: >Looks to me like you have SPOOLNEWS defined in the defs.h of your news >source. This directs rnews to spool all incoming to news to .rnews to be >unspooled at a later date by rnews -U [...] The presence of those files with the wonderful untypable names doesn't necessarily mean SPOOLNEWS is defined; if rnews decides that expire is running it will spool news in identical fashion. expire automatically calls rnews -U at the end of a run. ..b
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (03/21/88)
jc@minya.UUCP writes:
Well, it happened again, and I'm getting rather curious. The .rnews
directory here got very large, and was filled with a horde of empty
files. For assorted reasons, I'd doctored the news source so that
every call of system() was surrounded by output to stderr, which I
directed to an audit file. The following was in it:
Command: "/usr/bin/rnews -S -p 5153"
Status=0.
[etc.]
Anyone know what might be going on?
At a guess, you blew your news filesystem out of free-block space but
inodes were still available. When unbatching, I've seen this happen
because it tries to create a /usr/spool/news/.ar????? file, fails, and
tries to shuffle the article off to .../.rnews with the date-filename.
Working over the files later (maybe after expire), rnews -U dealt with
all the empty files.