fletcher@cs.utexas.edu (Fletcher Mattox) (05/11/89)
If you use DOT_LOCK, mush doesn't ignore signals in copyback() until
*after* the folder has been truncated. This can be Bad News if a
signal is received while trying to write back your spool mailbox.
Especially if disk io is a little sluggish, say because of an NFS retry
or two ...
And even after you have turned on IGN_SIGS, doesn't this code in
catch() defeat it?
if (ison(glob_flags, IGN_SIGS) && sig != SIGTERM && sig != SIGHUP)
return;
which suggests that HUP and/or TERM will not be ignored while writing
your folder.
The reason I ask is that we have seen a couple instances of corrupted
spool mail files with DOT_LOCK and HOMEMAIL defined in an NFS environment.
Fletcherschaefer@ogccse.ogc.edu (Barton E. Schaefer) (05/12/89)
In article <5505@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: } If you use DOT_LOCK, mush doesn't ignore signals in copyback() until } *after* the folder has been truncated. This can be Bad News if a } signal is received while trying to write back your spool mailbox. } Especially if disk io is a little sluggish, say because of an NFS retry } or two ... The fix for this (as best can be made) is twofold. First, stop special-casing DOT_LOCK for opening with "w+" and just let it be opened with "r+" and truncated later like everybody else. Second, turn on IGN_SIGS a little sooner, just before you do the truncation. We have to wait until after the lock_file() call because the user may want to interrupt the "waiting to lock" loop, but otherwise there isn't any good reason not to ignore signals before opening with "w". } And even after you have turned on IGN_SIGS, doesn't this code in } catch() defeat it? } } if (ison(glob_flags, IGN_SIGS) && sig != SIGTERM && sig != SIGHUP) } return; Sort of. TERM and HUP are just being lumped in with other signals that cannot be caught, like KILL. An NFS sluggishness shouldn't cause either of TERM or HUP to be sent. The trouble with HUP especially is that it indicates that mush really ought to exit -- it just ought to finish what it is doing first. Unfortunately, there isn't a portable way to defer the HUP signal and catch it later, so mush does the best it can. When somebody has time for a rewrite, the whole signal-catching mechanism will get an overhaul along with everything else. In the meantime, Patch #2 will move the IGN_SIGS to above the truncation. That should at least take care of some problems. Coming soon to a comp.sources.bugs near you. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer