Path: utzoo!attcan!uunet!van-bc!jtc From: jtc@van-bc.wimsey.bc.ca (J.T. Conklin) Newsgroups: comp.mail.uucp Subject: Re: Limiting Simultaneous 'uuxqts' on Pre-HDB UUCP Message-ID: <2588@van-bc.wimsey.bc.ca> Date: 15 Oct 90 19:11:49 GMT References: <1820@fallst.UUCP> Organization: UniFax Communications Inc., Vancouver, B.C., Canada Lines: 32 In article s872007@otto.bf.rmit.oz.au (David Burren [Athos]) writes: >In <1820@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes: >>Is there any way of limiting the number of simultaneous uuxqts in >>pre-HDB UUCP? I receive a pre-compressed newsfeed on my SCO Xenix >>2.2.3 box and find that once several rnews/uncompress processes >>get running, the machine is pretty much brought to its knees for >>doing any other (real) work. > >My understanding is that the limit on most non-HDB uucps should be one uuxqt. >When it starts up it checks for the file LCK.XQT, and if it's valid, it >assumes a job is already in progress. A problem I have observed is that pre-HDB SCO uuxqt erroneously considers the lock file stale if it is "too" old and starts anyway. This is likely to happen if you are processing a lot of compressed news. The way I solved the problem was to recompile bnews with SPOOLNEWS defined in defs.h. The SPOOLNEWS option causes all inbound news to be spooled, rather than unpacked, by rnews. Since spooling takes almost no time at all, uuxqt completes its job quickly, and there never is a chance for subsequent uuxqt's to find a "stale" lock. I ran "/usr/bin/rnews -U" every 15 minutes from cron to unpack news from the spool. The news lock mechanism must be more robust than what SCO used, as I never had any problems after I made the change. --jtc -- J.T. Conklin UniFax Communications Inc. ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca