mc68020@gilbbs.UUCP (Thomas J Keller) (09/11/86)
I have a problem with my uucico. When it finishes, it attempts to spawn
a uuxqt process, unless there is a LCK.XQT file in my uucp spool directory.
All well and good, except that if the LCK.XQT file is more than an hour old,
uucico blithely spawns another freaking uuxqt process!!! This results in
multiple uuxqt processes attaempting to process the same files, *MUCH*
disk thrashing, and a marked slowing of my machine.
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! *)csg@pyramid.UUCP (Carl S. Gutekunst) (09/16/86)
In article <900@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes: > When it [uucico] finishes, it attempts to spawn >a uuxqt process, unless there is a LCK.XQT file in my uucp spool directory. >... if the LCK.XQT file is more than an hour old, >uucico blithely spawns another freaking uuxqt process!!! >... why does it *DO* this >patently silly thing in the first place? 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>
mc68020@gilbbs.UUCP (Thomas J Keller) (09/16/86)
Yes, well. I have now had innumerable responses to my queries regarding
XQT lock files. Many people have suggested touching the file from cron. AS
it happens, that doesn't work.
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.
--
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! *)csg@pyramid.UUCP (Carl S. Gutekunst) (09/17/86)
In article <914@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes: > Yes, well. I have now had innumerable responses to my queries regarding >XQT lock files. Many people have suggested touching the file from cron. AS >it happens, that doesn't work. > > 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. 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>
mc68020@gilbbs.UUCP (Thomas J Keller) (09/18/86)
In article <614@pyramid.UUCP>, csg@pyramid.UUCP (Carl S. Gutekunst) writes: > In article <914@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes: > > Yes, well. I have now had innumerable responses to my queries regarding > >XQT lock files. Many people have suggested touching the file from cron. AS > >it happens, that doesn't work. > > > > 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. > > 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. > 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. -- 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! *)
rick@seismo.UUCP (09/18/86)
The prefered approch to faking the times on the files is to use chmod instead of touch. This changes the inode change time, which is what the locking is checking. It also does not leave a window like moving and copying. ---rick
lyndon@ncc.UUCP (Lyndon Nerenberg) (09/19/86)
In article <612@pyramid.UUCP>, csg@pyramid.UUCP (Carl S. Gutekunst) writes: > In article <900@gilbbs.UUCP> mc68020@gilbbs.UUCP (Thomas J Keller) writes: > > When it [uucico] finishes, it attempts to spawn > >a uuxqt process, unless there is a LCK.XQT file in my uucp spool directory. > >... if the LCK.XQT file is more than an hour old, > >uucico blithely spawns another freaking uuxqt process!!! > [...] > For your site, using cron to touch the LCK.XQT file is one solution; you can > [etc...] ^^^^^ 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
ahby@meccts.UUCP (Shane P. McCarron) (09/25/86)
In article <728@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >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 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!"
dan@rose3.UUCP (Dan Messinger) (09/25/86)
In article <728@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >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 fix is to change your crontab entry: > find /usr/spool/uucp/LCK* -exec touch {} \; > >Has anyone else run into this? See if you touch command has a -c option. This tells it to NOT CREATE the file. Dan Messinger ihnp4!rosevax!rose3!dan
perl@rdin.UUCP (Robert Perlberg) (09/25/86)
I have been using the following method on my machines (ONYX C8002M and
MASSCOMP MC500) for years now with great success:
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!perlcsg@pyramid.UUCP (Carl S. Gutekunst) (09/30/86)
In article <579@rdin.UUCP> perl@rdin.UUCP (Robert Perlberg) writes: >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. >... I don't >know why all programs that use LCK. files don't do this. 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>
sob@cortex.bcm.tmc.edu@soma.bcm.tmc.edu (Stan Barber) (10/03/86)
SYSV.2 UUCP checks the pid as well. I added modifications to kermit to
use this feature when it checks the LCK files. Unfortunately, kermit
on most systems cannot remove lock files since it usually requires setuid
priviledges to do so. With the LCK directory idea in 4.3 UUCP, this
is no longer an issue.
Stan
Stan uucp:{shell,rice,cuae2}!soma!sob Opinions expressed here
Olan domain:sob@rice.edu or sob@soma.bcm.tmc.edu are ONLY mine &
Barber CIS:71565,623 BBS:(713)790-9004 noone else's.