Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!rosevax!ems!questar!datapg!sewilco
From: sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <161@datapg.DataPg.MN.ORG>
Date: Thu, 12-Nov-87 09:48:11 EST
Article-I.D.: datapg.161
Posted: Thu Nov 12 09:48:11 1987
Date-Received: Sun, 15-Nov-87 12:03:17 EST
References: <283@paisano.UUCP> <728@nud.UUCP>
Reply-To: sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon)
Followup-To: comp.sys.att
Organization: Data Progress
Lines: 26
Xref: mnetor comp.sys.att:1755 comp.unix.wizards:5459

Some people have noticed a connection between the inode problem and
rnews running around the time when cronlog is cleared.

There is one thing which is unusual about rnews and cronlog:  rnews
can generate a lot of error messages to stderr, which can end up in
cronlog.  Most programs generate short cronlog messages, while rnews
is likely to run for several minutes and can easily generate several K
of unbuffered error messages.

If cronlog is unlinked while rnews is running, those error messages
will continue being placed in the phantom file.  If there's a bug,
it may be with this combination of long [unbuffered] output to a
phantom file.  

Testing will have to be done by someone with a system on which they
don't mind blowing away the inodes.

The workaround is to throw away the error messages by putting in the
rnews crontab entry
	>/dev/null 2>&1

The error messages will be placed in LIBDIR/errlog, if it exists.
-- 

Scot E. Wilcoxon	sewilco@DataPg.MN.ORG	{ems,meccts}!datapg!sewilco
Data Progress		Minneapolis, MN, USA	+1 612-825-2607