jorgnsn@qucis.queensu.CA (John Jorgensen) (02/22/89)
I have a short question, and a long explanation for why the
question is of interest.
We have a diskless Sun 3/160 running Sun Unix 3.5 that acts as
our uucp gateway to the world. The uucp spool directory is on an
NFS-mounted file system.
The simple question is, how do empty LTMP.<pid> files get
abandoned in the uucp spool directory? We average about four or
five of these abandoned files a day. LTMP files are one of the
things cleaned up by the daily uucp maintenance script
distributed by Sun, so someone must expect them to appear. I'd
like to know what particular circumstances cause them.
I glanced at some old (3.0) source, and it looks like LTMP files
are created by a routine called onelock() as part of the process
of creating a lock file. First the locking process tries to
create the file LTMP.<mypid>. If it succeeds, it tries to link
the name of the lockfile it is creating to the LTMP file.
Whether or not this link succeeds, the LTMP file is unlinked.
The only way that onelock() exits without unlinking LTMP is if
the initial creation of LTMP fails, which presumably means
there's no LTMP to unlink. In other words, I can't see how the
LTMP files ever live longer than a few fractions of a second.
This would only be of academic interest if it were not for the
fact that many, but not all, of these leftover LTMPs are
associated with lines in the ERRLOG file that read like:
ASSERT ERROR (uux) pid: 29603 (2/16-13:25) CAN NOT GET LCK.SEQL (0)
and all of these lines are associated with failed attempts to
send uucp mail by uux'ing rmail. The mail daemon sends the
postmaster a message like:
uux failed. code -1
554 hostname!userid ... unknown mailer error 255
I have a wildly speculative hypothesis for explaining these
failures: Uux locks the sequence number file to create the first
work file, but for some reason, the LTMP file used in the process
of creating the LCK.SEQL lock file doesn't disappear. As a
result, when Uux tries to lock the sequence number again to
create another work file, it fails, and puts the message into
ERRLOG. Even if this story is true, though, it comes back to the
question, why isn't the LTMP file deleted (and why is it empty?
onelockf() should write its process number into the LTMP file as
soon as it's created).
Someone here suggested that perhaps the fact that LTMP has been
deleted might not propogate through NFS's caches quickly enough,
so that it sometimes appears to the second locking attempt that
the file is still there. Is this conceivable?
I'm hoping there are some uucp wizards out there who can answer
this with ``But it's obvious that...''. You can mail responses
if this question is not of sufficiently general interest for
posted replies.
John Jorgensen
jorgnsn@qucis.queensu.casl@van-bc.UUCP (pri=-10 Stuart Lynne) (02/24/89)
In article <170@qusunc.queensu.CA> jorgnsn@qucis.queensu.CA (John Jorgensen) writes: >I have a short question, and a long explanation for why the >question is of interest. > >The simple question is, how do empty LTMP.<pid> files get >abandoned in the uucp spool directory? We average about four or I run a fairly ancient system V with what looks like a port of the V7 uucp (very early Unisoft, circa 1983/1984). As delivered we used to encounter a similiar problem, large numbers of LTMP files being left. When I installed a new serial driver which did a SIGHUP when DCD was lost the problem went away. No idea why or how; but that was the end result. Probably uucico is waiting for SIGHUP before exiting properly. Depending on how your system is configured you might want to check that you have your modem cables correctly wired. As a quick check, if a site is dialed into your system and running uucico, what happens if you turn the modem off. If you don't immediately see a message in the LOGFILE about catching a signal, then you have a problem. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532