Xref: utzoo comp.unix.wizards:5876 comp.mail.misc:729 news.software.b:1039
Path: utzoo!mnetor!uunet!husc6!think!ames!lll-lcc!pyramid!octopus!pete
From: pete@octopus.UUCP (Pete Holzmann)
Newsgroups: comp.unix.wizards,comp.mail.misc,news.software.b
Subject: Re: Another way that news eats inodes
Message-ID: <375@octopus.UUCP>
Date: 26 Dec 87 05:38:43 GMT
References: <440@minya.UUCP>
Reply-To: pete@octopus.UUCP (Pete Holzmann)
Organization: Octopus Enterprises, Cupertino, CA
Lines: 63
Summary: Hey! I've had this problem too. Is it a news bug?

In article <440@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
<[Discussion of how rnews sometimes eats all inodes in a filesystem...]
<[rnews seems to create gobs of temp files:]
<There are maybe half a dozen such files created per minute.
<[example ls output:]
<
<| total 0
<|   170 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 87122012501096
<|   352 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 871220125010a2
<|   389 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 871220125010a4
<|   126 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 871220125010a6
<|  5239 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 871220125010a8
<|   118 -rw-rw-rw-   1 news     news           0 Dec 20 07:50 871220125010ac
<
<This continues as long as rnews is running.  Note the "total 0".
<There are no news files in the directory; there are just these
<funny files whose names obviously start with a timestamp, plus
<plus something to make them unique.  This did happen of Dec 20
<at about 12:50.  The process number at this time was about 4000, 
<so the '5010*" isn't based on the process number.
<
<Anyhow, I killed off rnews, and discovered that the last batch
<of mail had not been unpacked.  I restarted it (with no news)
<just out of curiosity, and it did the same silly thing.  I
<killed that one, too.
<
<Luckily (actually, it wasn't luck; it was experience :-) I had 
<told /bin/rnews to also link the news files into another directory, 
<too, so I could just do a ln to put them back, and when I started 
<up rnews, it proceeded to unpack the news as if nothing was wrong,
<and it doesn't happen for several more months.

It started happening to me recently as well. I wasn't watching the system
closely, so I didn't get to it until things were in real bad shape: 12000
inodes get eaten up, and I'm getting complaints all over the console screen.
I reboot, fsck tells me that the inode count is wrong in my /usr/spool
partition (where news gets stored and unpacked), and we're back to normal
for another few days to few weeks. I've never been around when things started
going bad, so I've never found the culprit. Maybe this is it? Something is
very strange, since I can't imagine rnews having a valid need for so many
inodes no matter *what*! We don't get more than around 6-7000 articles in a
whole week!

<Is there something that
<I've done wrong, for which these files are evidence?

Same question here. I also agree with his complaint about rnews:

<BTW, there's also what I consider a bug in rnews here:  when
<it fails to unpack the news (in this case, because there are
<no inodes), it throws away the news file.... It would
<have been easier if there were someway I could tell rnews "If 
<you have trouble with unpacking a file, leave it in directory
<<X>, send me mail, and I'll take care of it."
<-- 
<John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

Do any of you news-hackers have any ideas? HELP!
-- 
  OOO   __| ___      Peter Holzmann, Octopus Enterprises
 OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
  OOOOO \___/        UUCP: {hpda,pyramid}!octopus!pete
___| \_____          Phone: 408/996-7746