vanni@mit-caf.UUCP (Giovanni Berti) (06/19/87)
We run the standard MAIL and sendmail under 4.3BSD. >>>> You might actually be loosing mail too <<<< The only reason why we saw the problem is because the user has biff set (biff yes) and stays loged on for several days at the same terminal. Therefore whenever sendmail deliver new mail to him, a message will remail on his screen. SYMPTOM User gets message (via comsat) that there is new mail, user enters mail, but no new message exists. Sometimes upto 2 successive messages have disappeared. BEHIND the SCENE Sendmail did actually attempt to deliver the mail. In some cases if /usr/spool/mail/$user was examined, prior to invoking mail to read the massage, a partial new message was found. In most cases new message had no header and only a portion of it was in the file. Note that if user had invoked mail, seen no message and quit, there would be actually NO TRACE of the message, except via the sendmail log file. Because of this one would typically think that it was user errror ... but it was NOT. This is not a reproduceable bug, and have been unable to reproduce it. But we have seen it occur an average of of several times a month for user which get an average of 10 message per day. NOTE also that the system and filesystem have been in very stable condition, so this has nothing to do with corrupted file or filesys. POSSIBLE EXPLANATION The user could have been loged on 2 terminals and actually running mail from at least one of the terminals. This could potentially cause the situation were 3 different programs are operating on the same file (/usr/spool/mail/$user). >> For example sendmail would be writing to the file, while >> the user could be closing the file. Does anyone know how MAIL handles these situations ??? Any suggestion will be apreciated. thanks in advance. -vanni
mangler@cit-vax.Caltech.Edu (System Mangler) (06/27/87)
In article <375@mit-caf.UUCP>, vanni@mit-caf.UUCP (Giovanni Berti) writes: > >>>> You might actually be loosing mail too <<<< > > The only reason why we saw the problem is because the > user has biff set (biff yes) and stays loged on for several [I'm using 4.2bsd /usr/ucb/mail] Any mail received between the time you give the "quit" (or ^D) command and when it finishes writing out $MAIL will be *lost*. This window of vulnerability is particularly troublesome if one's mail file is large, or the machine is slow, or you get a lot of mail. I lost two pieces of mail like that today. Mail received while the program is reading in $MAIL will be duplicated. One suspects that there is no locking at all. I never knew how much mail I was missing until I started using biff. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck