ccea3@rivm.UUCP (Adri Verhoef) (02/04/89)
Low free space on the system revealed some bugs in the news software.
Some configuration facts:
MINFREE == 5000
SPOOLNEWS not defined
LOCKF and READDIR defined
The system is UNIX System V.3.0 on a VAX-630 (microVAX-II).
Free space was low (~4000) at the moment I posted an article,
after I sent it, postnews said:
inews: Out of space in /usr/spool/news. Saving for later processing.
Article posted successfully.
So far so good, it seemed. But in the errlog file there was the message:
Feb 3 22:45 Unknown inews: Out of space in /usr/spool/news. \
Saving for later processing.
^^^^^^^ (I never saw this before. Should be the username.)
But the ability to put my username in errlog was still present, apparently,
for later on, the following entry showed up in the errlog file:
Feb 3 23:26 ccea3 inews: 8902032226d79: Inbound news is garbled
It's not the reason why I'm writing, though.
When the disk free space was still low, I tried 'rnews -U'.
The message that showed up on the screen, was:
inews: Out of space in /usr/spool/news. Saving for later processing.
and the program was waiting for input, for every time when
I typed a ^D, the same message showed up. ["Out of space..."]
Getting a process status:
$ ps -fttyB
UID PID PPID C STIME TTY TIME COMMAND
ccea3 1282 1 0 17:58:32 ttyB 0:04 -sh
ccea3 3377 1282 0 22:49:29 ttyB 0:00 rnews -U
ccea3 3378 3377 0 22:49:30 ttyB 0:00 rnews -S -p 8902032145d2a
After inputting more than 1024 chars (14 lines of 80 chars) and typing a ^D,
the /usr/spool/news/.tmp/spXXXXXX file stayed empty.
Finally giving up, I restored some free space, and typed another ^D
to the rnews -U that had been waiting for input all the time.
Free space: ~9555. Things really started happening then:
- On the screen:
inews: 8902032226d79: Inbound news is garbled
inews: rnews failed, status 256. \
Batch saved in /usr/spool/news/.bad/8902032226d79
- In /usr/lib/news/log:
Feb 3 23:26 local 8902032226d79: Inbound news is garbled
Feb 3 23:26 local rnews failed, status 256. \
Batch saved in /usr/spool/news/.bad/8902032226d79
- In /usr/lib/news/errlog:
Feb 3 23:26 ccea3 inews: 8902032226d79: Inbound news is garbled
Feb 3 23:26 Unknown inews: rnews failed, status 256. \
Batch saved in /usr/spool/news/.bad/8902032226d79
The .bad/* file was empty, clearly.
I had another try with low free space and typed 'rnews -U &'.
Not long after that, I had to kill the process, for messages kept
filling my screen (and the logfiles).
However, when disk free space was in order (~9555),
even 'rnews -U' worked fine, and there was no problem at all.
I dived into the code for another two hours, but the fight was unequal.
I restored things back to B 2.11.14 again. :-|james@bigtex.cactus.org (James Van Artsdalen) (02/05/89)
In <1243@rivm05.UUCP>, ccea3@rivm.UUCP (Adri Verhoef) wrote:
> Low free space on the system revealed some bugs in the news software.
The problem is that patches #15-17 try to save incoming articles
without immediate processing if the disk is too full. Unfortunately,
local articles are saved in the wrong format.
Try changing this in inews.c:
if (space()) { /* check disk space */
mode = PROC;
logerr("Out of space in %s. Saving for later processing.",
SPOOLDIR);
dospool((char *)NULL, FALSE);
into this:
if (space()) { /* check disk space */
spool_news = DO_SPOOL;
logerr("Out of space in %s.", SPOOLDIR);
After a little more testing, I'll post a patch to fix this and some
other nits (VOID_SIGNALS doesn't work, space() doesn't check for inode
deficiencies, expire doesn't always lock history.*, and so forth).
--
James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die"
DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789jiii@visdc.UUCP (John E Van Deusen III) (02/06/89)
>After a little more testing, I'll post a patch to fix this and some >other nits (VOID_SIGNALS doesn't work, space() doesn't check for inode >deficiencies, expire doesn't always lock history.*, and so forth). > >James R. Van Artsdalen james@bigtex.cactus.org My system is set up to spool local articles, and I get the "garbled" message. It has nothing to do with free space. As far as system V.0 goes, the new software does not work - I even found a syntax error. I am interested in getting it to work, but I am not inclined to apply patches that happen to episodically appear in this news group. This is no disrespect to Mr. Van Artsdalen or the other excellent programmers who might be working on this, but it was my understanding that Rick Adams was maintaining this software. Shouldn't we be working with him? -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii