[3062] in Athena Bugs
potential mh bug
daemon@ATHENA.MIT.EDU (mcdonald@ATHENA.MIT.EDU)
Fri Sep 1 11:56:03 1989
From: <mcdonald@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Date: Fri, 01 Sep 89 11:55:34 EDT
Yesterday, my NFS server clio was down for a while. I was already logged in
when it happened, and unthinkingly tried to do a 'scan' of my mail.
After a long time while it searched my path, it said "Creating standard
MH path for you". I am not sure what it meant to do, but I killed it
as quickly as I could. When I tried to 'comp'ose a message to bugs about
it, I got the same message, so I assume that this is common to many mh
commands. Later, when clio came back up, I could not use any mh commands
successfully until I had logged out and back in. It sounds like it was
reacting to a failed NFS connection as if my MAIL directory was not there.
Another thing I have noticed is that none of the signs in the clusters and
motd's recently have mentioned anything about the 6.2 release changes.
A number of students are now returning and may not realize what changes
occured in the 6.2 release. The largest problem is probably the change
in font names. Anyone who specified fonts in their .Xresources files
is affected by that, as well as some other less common uses of fonts.
I think you should make a little more advertising of those changes as
well as the 6.3 release. Another affect are the common X command arguments
-r (-rv) and -g (-geometry). Some people may not know why these don't work
any more, and won't know to look in the 6.2 release documents.
While I am writing this, I would also like to ask why users don't get any
notice when their machines are being taken down. Yesterday I noticed a
message on instance consult saying that clio would be brought down for
a few minutes (it ended up being a few hours) within an hour. But no
message was ever sent to the users on clio. I thought that was the main
purpose behind the 'zwrite -f' option. Knowing well in advance that a
machine would be taken out of service for a while and not informing those
users who are currently attached to that machine seems thoughtless to me.
Operations should try to be more consistent in sending class FILSRV messages
when they perform repairs.
Thank you for your attention.
Steve McDonald
