Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: news.admin Subject: Re: --- Multiple UUXQTs causing thrashing --- Message-ID: <8800@pyramid.pyramid.com> Date: Fri, 23-Oct-87 14:19:28 EST Article-I.D.: pyramid.8800 Posted: Fri Oct 23 14:19:28 1987 Date-Received: Sun, 25-Oct-87 16:37:53 EST References: <173@zap.UUCP> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 46 Keywords: Unix, compress, LCK.XQT, thrashing In article <173@zap.UUCP> fortin@zap.UUCP (Denis Fortin) writes: >A quick "ps -ef" informed me that no less than three UUXQTs were running on >the system, each one with associated news-unpack, compress, etc. Ah yes, the Great Glacier News Flood. :-) As you surmised, there must only be one uuxqt running at any one time; other- wise your have multiple daemons trying to process the same queue files. (Honey DanBer allows as many as you want, default two, and they don't get confused.) Uuxqt uses a lock file (variously named /usr/spool/uucp/XQT.LCK) to prevent multiple daemons. The problem is that all versions of UUCP except 4.3BSD and HoneyDanBer use an excessively simply mechanism for determining whether a lock is dead: the running uuxqt touches the lock file between each job, and any new daemons that get started override the lock if the c_time hasn't changed within the last hour. The assumption is that if uuxqt needed more than an hour to run a job, then it probably dumped core somewhere. On a small machine (anything smaller than a 68020, apparently) it's not that unusual for a single uncompress/unbatch/rnews run to take more than an hour. So the lock gets swept away, and another uuxqt starts running the same job. 4.3BSD and HoneyDanBer read the PID of the locking process out of the lock file, then use a kill(PID, 0) call to find out if the process is still alive. (All versions of UUCP write the PID into the lock file.) You have the following solutions available: - Regularly touch /usr/spool/uucp/XQT.LCK from cron. The most portable way to do this is: chmod 644 /usr/spool/uucp/XQT.LCK 2> /dev/null which alters the c_time if the file exists, and nothing else. - If you have UUCP source, you can increase the time on lock files to some hemungous number. If you are more ambitious, you can fix ulockf.c to check the PID instead; this only works in 4BSD and System V. - Enable SPOOLNEWS in Netnews src/defs.h, so all incoming news is held in the /usr/spool/news/.rnews directory. This allows uuxqt to run very quickly, since the time-consuming rnews is deferred. Then add 'rnews -U' to be run by cron every hour or so. Or if you don't have any impatient downstream loads, then run 'rnews -U' only after working hours, to completely relieve your machine of news processing during the day.