uuxqt bug with a badly logjammed spool directory
Mark Horton
mark at cbosgd.UUCP
Mon Oct 1 02:31:01 AEST 1984
Index: usr.bin/uucp/uuxqt.c 4.2
Description:
When there are a large number of X. files with no corresponding
D. files, uuxqt exits without doing any work.
Repeat-By:
Not easily reproduced. It happens when the first 20 X. files
in /usr/spool/uucp/X. all have F lines requiring files that
are not present.
Fix:
I don't have a fix, but can offer some insight into the bug.
There is a variable "rechecked" in gtxfile in uuxqt.c. It is set the
first time gtwrkf returns failure, so that the second time,
it will assume there is nothing to do and exit. Each gtwrkf
returns the first 20 files in the directory; normally each
time through this loop uuxqt will run 20 more programs and
remove them from the directory, and the next time 20 more
files will be found. However, X files that need a D file,
if the D file isn't present, will just be left there, cutting
into the 20 files per batch. If the first 20 files in the
directory are all X. files that need D. files that aren't there,
rechecked will be set and uuxqt will exit.
Just having it not set rechecked makes things worse - uuxqt
goes into a loop looking at the SAME 20 FILES over and over.
Note that the symptoms of this bug suggest the old "I forgot to
close a file descriptor" bug, but this bug has nothing to do
with unclosed file descriptors.
What I did as a temporary fix was to insert
unlink(subfile(file));
at the bottom of the routine gtxfile (right before the "goto retry"
at the bottom) to remove the dead X. files. I do not recommend
this fix for normal situations, since this would remove files that
are in transit or right after a phone line burp. An alternative
might be to stat the file, and if it's older than some cutoff
(a few hours, perhaps) unlink it.
The right fix is much harder - uuxqt has to remember all the
names of files it's already rejected and ignore them in
subsequent calls to gtwrkf.
I can think of some other possibilities as well. Running uuclean
before uuxqt would help. (This bug only appears when the spool
directory is badly jammed up, in this situation the filesystem had
been badly damaged.) gtwrkf might return a considerably larger
buffer than 20 files. Or it might just keep the directory open
and keep scanning, then restart when it runs off the end (with
some provision for stopping if a complete pass of the directory
is made with no work done.)
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list