Path: utzoo!attcan!uunet!decwrl!ucbvax!bloom-beacon!CSE.OGI.EDU!schaefer
From: schaefer@CSE.OGI.EDU (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: dead.letter locked twice
Message-ID: <9007310344.AA25603@cse.ogi.edu>
Date: 31 Jul 90 03:44:12 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 39

On Jul 31, 12:39am, Fletcher Mattox wrote:
} Subject: dead.letter locked twice
}
} This is 7.1.2 with DOTLOCK and HOMEMAIL defined.
} 
}   cs.utexas.edu% mush -n! fletcher
}   To: fletcher
}   
}   yo
}   ~q
}   /v/ai/v0/fletcher/dead.letter already locked, waiting................
} 
} which will wait forever.  Same thing happens with ~E and with
} generating two SIGINTs.  If I "set dead=~/somethingelse", then
} the problem goes away.

What this should mean is that you have a file called
    /v/ai/v0/fletcher/dead.letter.lock
which was for some reason left behind after a previous ~q or interrupt.
There may be some chance of a race condition on three rapid repetitions
of the interrupt character, but that would seem to depend on odd behavior
from the open() system call.

In any case, there is only one call to lock_fopen() in the dead-letter
sequence, and only one check for the file name, so if changing the file
name via $dead solved the problem, it isn't a bug in the dead-letter
part of the code.  You just need to remove that stray lock file.

It has in the past been suggested that the waiting-to-lock cycle should
eventually time out, but no one has yet convinced us of an appropriate
interval.  NFS-mounted mail directories could lead to delays of up to 15
minutes in writing back a file, depending on system timeouts.  When does
mush decide that enough is enough and ignore the lock?  (Yes, if the date
on the lock file is several hours old, it would be safe to assume that it
could be ignored.  I'll put *something* on the TODO list.  But does that
help for non-DOT_LOCK locks ... hmmm ....)

-- 
Bart Schaefer						schaefer@cse.ogi.edu