[1709] in Hotline Meeting
Re: BLDG 9-366 (LNO3 PROBLEMS)
daemon@ATHENA.MIT.EDU (dkk@ATHENA.MIT.EDU)
Fri Sep 14 01:33:47 1990
From: dkk@ATHENA.MIT.EDU
Date: Fri, 14 Sep 90 01:33:29 -0400
To: larugsi@ATHENA.MIT.EDU
Cc: hotline@ATHENA.MIT.EDU, operations@ATHENA.MIT.EDU
In-Reply-To: Louis A. Isgur's message of Thu, 13 Sep 90 18:13:50 EDT,
I saw that caes-p responds to ping, but not much else. Running
hostcheck solved the mystery:
------------
tisiphone% /afs/net/tools/@sys/hostcheck caes-p
sending......query session complete.
[caes-p 18.80.0.235]
machine type (0) MVAX-II
uptime (0) 7 hrs. 57 min. 48 sec.
public (0) false
realm (0) ATHENA.MIT.EDU
logins (0) 0
version (0) Athena Server (VS2) Version Update Thu Sep 13 16:16:18 EDT 1990
------------
Note the "version" line (the last one) returned by hostcheck. Any
"Version Update" line in the /etc/version file (which is where
hostcheck's "version" comes from, indirectly) indicates that the
system began an update. When the update completes, it appends a line
containing "Version 7.1H" or something similar.
What must have happened is that one of us was remotely logged in and
running an update beginning at 4:16pm. The system updated (as a
workstation) from 7.0F to 7.1H, then began running mkserv to restore
printservice. Before mkserv could finish, the gateway bounced
breaking the rlogin connection and thus aborting the update. Later
reboots didn't fix the problem because the filesystem is half-changed,
and missing a lot of programs.
What we need to do now is login on the console of caes-p, remove the
last line from /etc/version, and run "mkserv ops print" to finish what
we started. I believe this could have been prevented by invoking the
update as "nohup /srvd/update_ws". The nohup makes update_ws keep
running if the connection is closed. We should probably consider
using nohup for all remote server updates.
Thanks, Lou, for a very informative and concise report.
