I've finally gotten around to upgrading our AXPs from V3.0 to V3.2,
and in doing so I stumbled across a problem that didn't previously
exist.
The first system I installed V3.2 on has a CD-ROM reader, and all
went well. The second system doesn't have one, so I needed to do
the firmware update (and the OSF/1 installation) across the network,
using the first system as the bootp+tftp server.
The instructions on the Firmware Update CD include the following in
the "BOOTP Network Upgrade" section:
[ much verbiage, including how to modify inetd.conf ]
- Find the process of /usr/sbin/inetd daemon. [...]
# ps aux | grep ine
# kill <ine process number>
- Restart the inetd daemon:
# /usr/sbin/inetd
Unfortunately, for all the users who were already logged in on the
first system, killing inetd now kills the rlogind processes spawned
by inetd (and the shells running as subprocesses of rlogind procs).
In V3.0, this didn't happen. One could kill and restart inetd with
no horrible side-effects. Is this new behaviour intentional? If it
is, shouldn't the change have been documented in the release notes?
If it's a bug, will it be fixed in the next release?
And, whether bug, misfeature, or intentional change, is the problem
specific to inetd, or is it a more generic change to the way signal
delivery is implemented?
And regardless, is there any particular reason that the AXP Firmware
Update documentation tells us to "kill inetd_proc" and then restart
it, rather than doing a "kill -HUP inetd_proc", which would have the
same effect (but presumably without the nasty side-effects)?
Mark Bartelt 416/978-5619
Canadian Institute for mark_at_cita.toronto.edu
Theoretical Astrophysics mark_at_cita.utoronto.ca
"Nur eine Waffel taugt!" -- Parsifal, in an Eggo commercial
Received on Thu Jul 06 1995 - 21:04:05 NZST