From: roberts@nimrod.wpd.sgi.com (Robert Stephens)
Subject: Re:  Mail lockin
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 29 Sep 1992 17:57:43 GMT

rweisbe@starfleet.nswc.navy.mil (Bob Weisbeck) writes:
>
>   The user was logged in via their pc and typing in a reply to a mail 
> message via Mail. For some reason his pc was powered down (actually 
> some came in to talk and bumped the off switch if you can believe that).
> Any how when the user logged back in he could not delete any of his mail
> messages.  I looked in /usr/mail and saw a username.rolock file. In the
> file was the number 344. That is the pid of the user's mail process.

IRIX Mail uses two kinds of lock file:

	username.lock	The "standard" mailbox lock file.  This file is
			created in the /usr/mail directory and contains
			the pid of the creating process.  The existance
			of this file prevents any other cooperating process
			(other instances of Mail, or /bin/mail for example)
			from either reading or writing the /usr/mail/username
			mailbox.  This lock should only be held for short
			periods while the locking process is actually reading
			from or writing to the mailbox.  The purpose of this
			lock file is to prevent races between multiple
			processes delivering mail and between processes
			delivering and reading mail.  This is the lock that
			prevents two simultaneously-received messages from
			being interleaved in the mailbox, and prevents your
			mail reader from ever seeing an incomplete, only
			partially-delivered message.

	username.rolock	The IRIX "read only" mailbox lock file.  This file
			is created in the /usr/mail directory and contains
			the pid of the creating process.  The existance of
			this file prevents any other cooperating process
			(other instances of Mail) from altering the contents
			of the mailbox.  This lock will be created by the
			first instance of Mail to open the mailbox, and will
			be held until that instance of Mail exits, or selects
			another mailfile for viewing.  The purpose of this
			lock file is to prevent two instances of Mail from
			simultaneously altering the mailfile.  This is
			necessary because of the way in which Mail detects
			new messages that were delivered during the Mail
			session.  Mail assumes that the only changes to the
			mailfile other than its own are the addition of new
			messages at the bottom of the mailfile.  Thus, new
			messages are detected by seeing if the mailfile is
			larger at the end of the Mail session than it was at
			the beginning.  If a "last writer wins" policy were
			used (no .rolock), it would be possible to loose new
			messages.  For example, suppose we have a mailbox
			containing 10 messages and suppose two instances of
			Mail, A and B, both open that mailbox.  Now suppose
			one new message is delivered to the mailbox.  If
			Mail instance A were to delete all 10 messages in
			the mailbox and quit, it would see that the mailbox
			was larger than when it opened it (due to the new
			message) and would preserve that new portion of the
			mailbox beyond the original end of the mailbox.  So
			when instance A exits, the mailbox will contain only
			the new message.  Now suppose Mail instance B decides
			to delete only messages 1 and 2 before quitting.
			When it quits, it would compare the original size
			of the mailbox with the current size and (most
			likely) would find that the new size is not larger
			than the original size so it would assume that no
			new messages were delivered and it would simply
			overwrite the mailbox with messages 3-10 thus
			obliterating the new message!  The .rolock file
			prevents this from happening.

Note that these locks are actually used on any file opened by Mail.  The
lock files are always created in the same directory as the mailfile itself.
I have only described the case of the mailbox above.

> I moved the file to another name and the user was able to process mail 
> like normal. But I still have the original shell and mail process
> in the system. I thought if I removed the .rolock file it would clean 
> up these processes; but it did not. (ps -ef is what I'm using to 
> determine if the processes cleared up). 

Removing the .lock or .rolock files has no effect on the processes that
created them, however, killing any process that is currently holding a
.lock or .rolock file will render the associated lock file invalid because
the pid in the remaining .lock or .rolock file will no longer belong to a
"live" process.  Any Mail or /bin/mail process attempting to acquire a
.lock or .rolock file will check to see if the pid contained in the file
belongs to a real process.  If not, or if the pid is the processes' own pid,
the lock file will be considered invalid and the current process will write
it's own lock file and acquire the lock.

>   So my questions are:
>     
>     1) Should I have renamed or removed this lock file? It seemed to 
>        be ok this time but what problems could it have created?

Since you knew the old process was defunct(?) it was reasonably safe to
remove the .rolock file.  It would have been better to have killed the
defunct process.
   
>     2) Is there a method for preventing the user's mailbox from being
>        locked up under such circumstances?

Not if there are defunct processes hanging about.  I don't understand why
the process is not getting cleaned up when the PC hangs up (gets turned off).
 
>     3) I realize that phathom(sp) processes will be in the system from
>        time to time and that in this case mail had something to do with
>        creating them. I was able to do a kill -9 on the sh process and
>        they went away but could this also have screwed up the user's 
>        mailbox?

Not in this case.

>                  Are there some guidelines that one should follow 
>        cleaning up mail or other processes? I realize no one really 
>        knows what a process is doing, thus killing it may cause problems
>        but what is the best way to do this to prevent any problems? 
>        In this case nothing bad happened but I may have been lucky.

You shouldn't have to do this.  It's a bug that the old processes are not
being cleaned up.  Shouldn't those processes get a SIGHUP when the PC goes
dead?

	- Robert Stephens
	  Silicon Graphics Inc.

Newsgroups: comp.sys.sgi