Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!ames!pacbell!att!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: news.software.b Subject: Re: relaynews failing with status 16 (full disk) Summary: That is not the problem (ulimit) Message-ID: <1989Jul23.164648.10868@ddsw1.MCS.COM> Date: 23 Jul 89 16:46:48 GMT References: <1989Jul22.211235.17447@utstat.uucp> Reply-To: karl@ddsw1.MCS.COM (Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 34 In article <1989Jul22.211235.17447@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >With one exception (when the standard file descriptors are found to be >closed during startup), relaynews writes an error message on standard >error (a.k.a NEWSCTL/errlog) when it exits with non-zero status. In the >case of a full disk, the name of the file being written when the disk >filled is included in the error message. (Of course, the error message >may not be visible if NEWSCTL's file system just filled.) Those of you >running System V will see an apparently-spurious full-disk complaint >when any file exceeds your ulimit; this most often hits the history and >log files. This is not the problem. We get the same spurious message on occasion here running Xenix System V/386 2.3.2. The batch IS correctly processed through to the end, but something which is done at the very end of the batch is returning a status 16... It is _not_ ulimit-related -- our ulimit is set to 32k! What is more strange is that it only happens once a day or so -- once out of about 20-30 batches on average! Nothing indicating the cause of the problem has been found in the log files. This is an annoyance, but not a serious problem -- we just "rm" the files in the "bad" area once in a while. It would, though, be nice to know what is doing this and squash it. -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"