Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helps!uudell!pensoft!mike
From: mike@pensoft.uucp (Mike Heath)
Newsgroups: news.software.b
Subject: Re: what does this msg mean (B news 2.11): "waiting for lock on..."
Message-ID: <1991Apr18.222927.454@pensoft.uucp>
Date: 18 Apr 91 22:29:27 GMT
References: <1557@beaudin.UUCP>
Organization: Pencom Software, Austin, TX
Lines: 34

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