john@beaudin.UUCP (John Beaudin) (04/18/91)
Also, sometimes my system starts using a LOT of swap space during news article unpacking: today it used about 16MB. I'm using SCO Unix 3.2.2. Usually, though, there's no problem. -- "The Battle of the Gulf was won on the playing fields of Atari" - J. Beaudin My permanent .signature is awaiting apropriate display technology
mike@pensoft.uucp (Mike Heath) (04/19/91)
In article <1557@beaudin.UUCP> john@beaudin.UUCP (John Beaudin) writes: >Also, sometimes my system starts using a LOT of swap space during >news article unpacking: today it used about 16MB. I'm using SCO Unix 3.2.2. > >Usually, though, there's no problem. As for waiting for lock on... A couple of months ago (when I was running B-news), I was getting this message (almost) like crazy. rnews (for some reason) creates a lockfile in /tmp (on my system at least) for every incoming article that is processed. On my system, it was naming the lockfile '/tmp/Larticleid' where 'articleid' is replaced by the actual article id. Now, it turns out that my system has a 14 character filename limit, and looking at the article ids, I was getting a *lot* of article ids of the form: <1991mar21.05438.15987@site.com> All that had to happen was the first two characters after the first '.' needed to be the same. I never did find out why some lockfiles were being left behind while most weren't, but it was causing *major* delays in news being unbundled. It sleeps (for up to 10 minutes) waiting for the lockfile to go away. What I did to fix the problem (before switching to cnews, believe Henry, it is *much* faster) was modify the routine idlock() in ifuncs.c to move a few more characters down if the first five characters of the article id were '<1991'. That was my temporary fix, my real fix was to switch to cnews. Hope this helps. -- Mike Heath Pencom Software pensoft!mike@cs.utexas.edu