Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!ut-ngp!infotel!pollux!jgd
From: jgd@pollux.UUCP (Dr. James George Dunham)
Newsgroups: comp.unix.questions,news.sysadmin
Subject: Re: uuxqt problems with news
Message-ID: <311@pollux.UUCP>
Date: Tue, 19-May-87 14:22:27 EDT
Article-I.D.: pollux.311
Posted: Tue May 19 14:22:27 1987
Date-Received: Sat, 23-May-87 10:18:39 EDT
References: <116@bvax.UUCP>
Reply-To: jgd@pollux.UUCP (Dr. James George Dunham)
Organization: Department of Electrical Engineering; S.M.U.; Dallas, TX
Lines: 29
Keywords: news, VAX 730, HELP!
Xref: mnetor comp.unix.questions:2458 news.sysadmin:210

In article <116@bvax.UUCP> dave@bvax.UUCP (Dave Wallace) writes:
>
>I recently joined the 'net but have a problem. I am running System V,
>Release 2.2 on a VAX 730( No, that's NOT the problem). When I get my
>'feed', uuxqt runs, forking a sh, who forks a sh, who forks a
>compress and rnews,( plus the compress forks an unbatch). I can
>get up to 6 of these running at once, which causes the 730 to slow down
>just a bit (-: . I currently get my feed from one site and don't send
>to anyone else ( until I get this problem resolved. ) It takes the 730
>most of a working day to process 6 or 7 batch files in /usr/spool/uucp! It
>seems like these processes are fighing them selves. Any body have
>any suggestions? 

    We reduced the priority of our news jobs so they would not interfere
with other users doing work on our system and have a similiar problem.
It seems that the lock on uuxqt is a timed lock, and so if you have a uuxqt
job running for a long time and someone else calls, they can start a new
uuxqt job if the time on the lock is expired. We have seen several uuxqt
jobs get started when we have long jobs running in the background. On our
system the problem get worse since it appears there is a limit to the number
of processes one user can run. When the limit is reached, then everything
comes to a halt.
     I feel that the correct solution is to make the lock on uuxqt a pid
lock rather than a timed lock. This way, only one copy of uuxqt can run
at a time. If uuxqt is killed for some reason, then the pid will be wrong
and a new one is allowed to start up. A quick fix is to lengthen the time
of the lock which is X_LOCKTIME in uucp.h and when multiple jobs are found,
kill all but the oldest one. I am hoping to get the lock changed to a pid
lock this summer.