dave@lsuc.UUCP (12/16/86)
We're running 2.11 on a Perkin-Elmer 3220 running Edition VII (v7).
SPOOLDIR is defined.
Our news is coming in OK, but I'm getting regular "inbound
news is garbled" logs from inews. I've run rnews -U by hand a
couple of times after posting articles during the day. Several
times (not all the time) I've gotten a Memory fault: core dumped
message from the background process. I've checked .rnews and
found a 0-byte core file in it. This file is evidently what causes
inews to complain "inbound news is garbled". The 0-byte core file
gets "processed" and removed in a matter of seconds, by the same
rnews program that started up something which dumped core.
I've set the stack on inews/rnews to 16k (stack size max has to
be preset on P-E binaries or they can bomb), so I don't think that's
it. Any ideas what might be the problem? All help appreciated.
Incidentally, rnews -U really should file away (in .rnews/bad or
somewhere) anything it can't process. There may be stuff in there
which can be dealt with by hand. It should also mail $NEWSADMIN
what it finds a problem. Has anyone done this yet, so Rick can
publish it as an official patch?
Another minor annoyance: inews logging
freopen(861208061971CD): No such file or directory
a few or many times each night. It only shows up late at night, around
the time that I suspect expire is finishing. I think what's happening is that
expire is starting up rnews -U and it's conflicting with the one started
from crontab. Since we start it hourly from crontab anyway,
I've stuck an xxit(0); into expire.c just before the execl of
rnews. I think that might solve it.
David Sherman
The Law Society of Upper Canada
Toronto
--
{ ihnp4!utzoo seismo!mnetor utai watmath decvax!utcsri } !lsuc!davedhb@rayssd.UUCP (12/22/86)
In article <1457@lsuc.UUCP>, dave@lsuc.UUCP (David Sherman) writes: > Another minor annoyance: inews logging > freopen(861208061971CD): No such file or directory > a few or many times each night. It only shows up late at night, around > the time that I suspect expire is finishing. I think what's happening is that > expire is starting up rnews -U and it's conflicting with the one started > from crontab. Since we start it hourly from crontab anyway, > I've stuck an xxit(0); into expire.c just before the execl of > rnews. I think that might solve it. I have found an even bigger problem with the alleged interlocking between expire and rnews. When expire is running it locks the active file which causes rnews to go into spooling mode (which I have defined anyway). The only problem is that the -U flag ignores the fact that the active file is locked and proceeds to process the spool directory. It is also possible to have more than one rnews -U running since they each ignore the fact that the active file is locked. What I did was to make the routine that does the unspooling attempt to create an exclusive lock on the active file and refuse to run if the lock cannot be created. Of course you then have to be careful to downgrade the lock to shared or else other things will probably cease functioning. These changes have only been tested on 4.2BSD and have not been mailed to Rick Adams yet, but if anyone wants them they may have them. -- David H. Brierley Raytheon Submarine Signal Division; Portsmouth RI; (401)-847-8000 x4073 smart mailer or arpanet: dhb@rays