Xref: utzoo comp.unix.wizards:5874 comp.mail.misc:728 Path: utzoo!mnetor!uunet!husc6!mit-eddie!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.wizards,comp.mail.misc Subject: Another way that news eats inodes Message-ID: <440@minya.UUCP> Date: 25 Dec 87 14:27:42 GMT Organization: home Lines: 72 Here's another file-system puzzle to entertain y'all over the holiday season. About once every two months, I've seen all the inodes disappear in the news filesystem here, with similar symptoms. This is one of the machines where /bin/rnews is a script that just stuffs the news file into ~news/spool/.rnews, and a couple of times a day cron runs a script that does "rnews -U" to unpack it all. This usually works just fine, and solves the problem that rnews, compress, and uucico don't seem to be able to coexist with vi or cc here. But occasionally all the inodes disappear, and when I investigate, I find something curious: | drwxrwxrwx 2 news news 40656 Dec 20 07:44 .rnews This is rather large for a directory; what it contains is: | total 0 | 352 -rw-rw-rw- 1 news news 0 Dec 20 07:49 8712201249103d | 118 -rw-rw-rw- 1 news news 0 Dec 20 07:49 87122012491045 | 2845 -rw-rw-rw- 1 news news 0 Dec 20 07:49 87122012491047 | 170 -rw-rw-rw- 1 news news 0 Dec 20 07:49 87122012491049 | 389 -rw-rw-rw- 1 news news 0 Dec 20 07:49 8712201249104b | 126 -rw-rw-rw- 1 news news 0 Dec 20 07:49 8712201249104f and so on for pages and pages. There are maybe half a dozen such files created per minute. I did a "rm .rnews/*", and checked again: | 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. Does anyone out there have any idea what might be going on in rnews' feeble little mind when it creates these funny files? I've spent a little time trying to spot the code that creates them, but so far I've had no luck. Is there something that I've done wrong, for which these files are evidence? 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. I've done an end run around this by, as I said above, linking incoming news files into a secret directory, and running a separate cleanup script that deletes them after a couple of days. But 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 , send me mail, and I'll take care of it." -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)