Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!itivax!vax3.iti.org!scs
From: scs@vax3.iti.org (Steve Simmons)
Newsgroups: comp.mail.elm
Subject: Problem With Network Disconnects And Locks
Summary: why flock *and* foo.lock
Message-ID: <996@itivax.iti.org>
Date: 20 Apr 89 21:49:00 GMT
Sender: news@itivax.iti.org
Reply-To: scs@vax3.iti.org (Steve Simmons)
Organization: Industrial Technology Institute
Lines: 35


Maybe we should start comp.mail.elm.scs... :-)

Found an interesting little problem that I'm too ignorant to really
address.  Information on why things are done the way they are would
be really appreciated.

Basic data: 4.3BSD, elm 2.2, patchlevel 1.

I was telnet'ed in from a remote host to my mail host, reading mail
with elm, when the gateway crashed.  When things came back, on
starting elm I got a series of "Waiting to read mailbox while mail
is being delivered..." messages, followed by elm exiting.  There was
a file named scs.lock in /usr/spool/mail.  Rather than just blast it,
I went and read the BSD mail, rmail, Mail and sendmail code.  All
of it uses flock() to do mailbox locking.  So *then* I blasted the
lock, and all was OK.

I read the locking code for elm, and can see no reason whatsoever to
have this lock file under BSD.  If it's only for elm, flock() should
do the job.

Along the way I patched the elm locking code to not only create this
lock, but put the PID of the creator in the file.  My first thought was
to try to do a kill( pid, 0 ) in elm to see if the locker was still
around and blast the lock if not.  That proved ineffective (eg, if it
was locked by root, one cannot send the kill signal and can't determine
just why the kill failed).  Yes, there is more I can do but we're
getting into some pretty non-portable areas.  Before doing that work
(I volunteer) can anyone explain to be why to bother with the lockfile
at all under BSD?

   Steve Simmons         Just another midwestern boy
   scs@vax3.iti.org  -- or -- ...!sharkey!itivax!scs
         "Hey...you *can* get here from here!"