I am led to believe that this is a well known and recognized problem. I
would be forced to call it a bug, frankly. Why is it that people don't
refer to it as such?
More to the point, and of much greater interest, why does it *DO* this
patently silly thing in the first place? (note, I have no source license,
so I cannot fix this for myself) I would appreciate someone knowledgable
taking the time to explain this situation to me. I have had to develop a
rather arcane little shell script, running out of crontab on an hourly
basis, to protect my poor system from being thrashed to death by uucico/uuxqt.
Thanks.
--
Disclaimer: Disclaimer? DISCLAIMER!? I don't need no stinking DISCLAIMER!!!
tom keller "She's alive, ALIVE!"
{ihnp4, dual}!ptsfa!gilbbs!mc68020
(* we may not be big, but we're small! *)
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. :-)
<csg>
According to a contact at a site with source license, UUCP checks the
CREATION time, as opposed to the modification time of the lock file. I have
therefore developed a strange but functional script which handles this for
me. In the very near future, I intend to follow the many suggestions that I
divorce news unbatching from UUXQT. Here is the script I developed that
finally seems to have accomplished what I needed:
----------------------------------------------------------------------------
if test -f /usr/spool/uucp/LCK.XQT
then
if (ps -elf | grep "uucp[a-zA-Z0-9 :]*UUXQT")
then
nice --10 copy -o /usr/spool/uucp/LCK.XQT /usr/spool/uucp/newlock
nice --10 rm /usr/spool/uucp/LCK.XQT
nice --10 mv /usr/spool/uucp/newlock /usr/spool/uucp/LCK.XQT
echo "Lock file updated \c" >> /hd1/lib/news/xqt.log
date >> /hd1/lib/news/xqt.log
else
sleep 90
if (ps -elf | grep "uucp[a-zA-Z0-9 :]*UUXQT")
then
exit 0
else
rm /usr/spool/uucp/LCK.XQT
echo "Lock file removed \c" >> /hd1/lib/news/xqt.log
date >> /hd1/lib/news/xqt.log
fi
fi
fi
--------------------------------------------------------------------------
Any constructive comments are more than welcome. I am not a highly
expereinced shell programmer, so I'm sure there are better ways to
accomplish this task. Flames regarding this script politely referred
to /dev/null.
Your contact with a source license should learn to read man pages. :-)
This gets hashed out in unix-wizards every six months or so: there's no such
thing as "creation time." UUCP checks ctime, which is the the "last status
change time," literally the last time the inode changed. Since pretty darn
near anything you can do to a file changes the inode, touching the lock file
works just fine.
<csg>
Well, i am an egg. I will not presume to argue with someone of Carl's
experience regarding UNIX internals. All I can say is that when I had a
shell script merely "touching" my XQT lock file, I occasionally still wound
up with additional XQT processes running (sometimes with as little as a few
minutes between start-times). When I altered my script to actually COPY the
lock file, remove the original and copy the copy back to the original name
again (all with a nice --10 in front of it) the problem seems to have gone
away.
I am going to remove news unbatching from the purvue of uuxqt, which is
a better approach anyway.
Thanks to everyone for their assistance and patience.
It also does not leave a window like moving and copying.
---rick
Be careful how you do this! We run a CT MiniFrame, and this bug may be
specific to CTIX, but...
I set up cron to "touch /usr/spool/uucp/LCK*" once per hour for the same
reasons. If there are no LCK files in the directory, touch creates a file
named "LCK*". The next time you run "uucico -r1" from cron, it sees queued
up XQT's and trys to run them. *Sometimes* (but *not* always), the presence
of "LCK*" makes uuxqt get very upset, at which point it dumps all the queued
jobs!! The fix is to change your crontab entry:
find /usr/spool/uucp/LCK* -exec touch {} \;
Has anyone else run into this?
--
Lyndon Nerenberg (VE6BBM) {ihnp4,ubc-vision}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp. Envoy_100: Unix
The problem here is that touch will create a file when you say touch
filename UNLESS you say touch -c filename. The correct cron entry is
'touch -c /usr/spool/uucp/LCK*'.
--
Shane P. McCarron UUCP ihnp4!meccts!ahby
MECC Technical Services ATT (612) 481-3589
"They're only monkey boys; We can still crush them here on earth!"
See if you touch command has a -c option. This tells it to NOT CREATE the
file.
Dan Messinger
ihnp4!rosevax!rose3!dan
Every hour, cron runs a program I call lckcheck.
lckcheck searches for LCK. files in /usr/spool/uucp. For each LCK.
file, it opens the file and reads the PID from it. It checks the
existence of the process that created the LCK. file by sending a signal
#0 with kill(2). If the process does not exist, the file is removed.
If the process does exist, the file is touched. This program is also
useful for when you suspect that a LCK. file might be associated with
a dead process, but you don't want to remove it just in case it isn't.
I also use it to provide getty(8) with a way of creating LCK. files.
Since getty is never around when the shell process dies to remove the
LCK. file it created before exec'ing the shell, the next getty uses the
lckcheck technique to verify the validity of the LCK. file. I don't
know why all programs that use LCK. files don't do this. Why do
programs that don't use the PID for verification put the PID there in
the first place?
Robert Perlberg
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl
Problem is that kill(0,pid) is a relatively new feature of UNIX. V7 and System
III do not have this capability. This is why I called the one-hour-lockfile-
removal an anachronism: early versions of UUCP had no choice; newer versions
could check the PID but rarely do. (Exceptions are 4.3BSD and HDB. I've been
told that Ultrix 1.2 UUCP checks the PID also.)
Since the system that raised the question is a Tandy 6000 running Xenix, they
have no choice either (even if they had sources).
>Why do programs that don't use the PID for verification put the PID there in
>the first place?
So humans can use ps(1) to find out if the process is still active.
<csg>
Stan uucp:{shell,rice,cuae2}!soma!sob Opinions expressed here
Olan domain:s...@rice.edu or s...@soma.bcm.tmc.edu are ONLY mine &
Barber CIS:71565,623 BBS:(713)790-9004 noone else's.