Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!cit-vax!amdahl!pyramid!csg From: csg@pyramid.UUCP (Carl S. Gutekunst) Newsgroups: net.bugs.uucp Subject: Re: uucico/uuxqt bugs...howcome? Message-ID: <612@pyramid.UUCP> Date: Tue, 16-Sep-86 02:31:53 EDT Article-I.D.: pyramid.612 Posted: Tue Sep 16 02:31:53 1986 Date-Received: Tue, 16-Sep-86 06:47:44 EDT References: <900@gilbbs.UUCP> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 34 In article <900@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes: > When it [uucico] finishes, it attempts to spawn >a uuxqt process, unless there is a LCK.XQT file in my uucp spool directory. >... if the LCK.XQT file is more than an hour old, >uucico blithely spawns another freaking uuxqt process!!! >... why does it *DO* this >patently silly thing in the first place? It's actually uuxqt itself that checks for the lock, not uucico, but that's an irrelavant nit.... This is one of many anachronisms in UUCP. The assumption being made is that no single command run by uuxqt will ever need more than one hour to complete; a lock more than 1 hour old is presumed to be 'dead' and is removed. Indeed, in Ye Goode Olde Days it *was* more common for uuxqt to core dump that for it to run correctly for an hour. Today, on a small machine uncompressing big news batches, this is no longer true. (And when I say small, I'm including mid-size VAXen. Remember the Great Glacier News Flood?) Since the LCK.XQT file contains the PID of the process that created it, newer versions of UUCP test to see if a process with that PID is still running. The same check is also used for device and system LCK files. (Actually, as far as I know only HoneyDanBer does this, although both 4.2bsd and System VR2 make it easy to check.) For your site, using cron to touch the LCK.XQT file is one solution; you can instead modify rnews to touch it after every 'n' articles. Or do what Brian did with Glacier, and use a queueing system for incoming news so that you don't run compress|unbatch|rnews from uuxqt. You can also use smaller news batches, which will run through compress more quickly. Or you can buy a bigger computer. :-)