oneill@bu-tyng.bu.edu (Brian O'Neill) (09/23/89)
Lately I've heard complaints that on occasion people receive notification of
new mail, when if fact the mail is for another person (I don't use biff, so
I haven't had the problem). It seems that after the Multimax has been
running for a long time (> 3-4 weeks), comsat isn't getting the right
information from /etc/utmp. Say, if user "x" is logged on, and user "y" gets
mail, "x" may get the notice. If "y" was logged in at the time, and "x" got
the notice, "y" does not. "y" does not have to be logged in at the time.
Unfortunately, I can't supply much more information, as it's something that
can't be easily recreated. UMAX version is 4.2 R3.3_0
Has anyone experienced similar problems?
--
===========================================================================
Brian O'Neill - Boston University Corporate Education Center, Tyngsboro, MA
UUCP: {decvax|ulowell}!bu-tyng!oneill
Internet: oneill@bu-tyng.bu.edu (508) 649-9731 x14csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/05/89)
In article <2069@bu-tyng.bu.edu> oneill@bu-tyng.bu.edu (Brian O'Neill) writes: >Lately I've heard complaints that on occasion people receive notification of >new mail, when if fact the mail is for another person.... It seems that after >the Multimax has been running for a long time (> 3-4 weeks), comsat isn't >getting the right information from /etc/utmp. The problem is it isn't rereading /etc/utmp. This is from a bug in the 4.2BSD version of sleep(3). (It goes to sleep an never wakes up.) The bug is fixed in 4.3BSD; a quick diff of the two makes it painfully obvious. There is also a bug in the 4.2BSD interval timers that will only show up on a multiprocessor system and that exhibits the same behavior. <csg>