The network interfaces are shutdown before all processes are
killed, resulting in network connections not being properly
closed. For example, a telnet or SSH connection to the host
being shutdown remained connected as far as the client is
concerned. Since the network interface is down, when the
processes are finally killed, the RST/FIN packets are not
transmitted to the client host.
The workaround is to delete /etc/rc.d/rc.d/K90network.
But this leaves the network up when the kernel is halted and
the kernel continues to response to pings (and undesireable
IMHO, all processes not involved in shutting down should be
killed prior to network interface shutdown, and network
interfaces should be shut down before final halt/reboot. I
have attempted to reorder the initscript links to place
"network" as late as possible without success, so there
appears to be something more fundamentally wrong than just
the sequence of links.
This was first seen in 5.1 for Intel and Sparc, seen also in
5.2 for Intel and Sparc, and seen in 6.0 for Intel (I have
not upgraded my Sparc 5 to 6.0, yet). The severity is
reported as low because there is a workaround, but I do
consider the incorrect ping response to be somewhat higher
severity than low.
Thank you for your suggestion. I have passed it on to a developer for
------- Additional Comments From 09/01/99 12:53 -------
This particular problem can be worked around by putting a call to
"/etc/rc.d/init.d/network stop" in /etc/rc.d/init/halt after the
"sending all processes the -9 signal" (e.g. for redhat 6.0 at line 49
of /etc/rc.d/init.d/halt (and deleting the K90network). That way the
proesses are all killed before the network shuts down, and it in turn
is shut down before the kernel halts.
However, this does not solve the generic problem with the shutdown
scripts. Specifically, the user logins are not killed until far far
too late. E.g. there are always problems shutting down autofs because
there are still user processes using remote file systems. All user
sessions should be killed at the *start* of the shutdown and not at
the end. This is logical, since it is the fully configured set of
setvices which are started in order for the users to log in --
therefore the shutdown should be in the reverse order.
Another way of looking at it is that although killing getty kills
sends a HUP to the session, and killing X sends a HUP, that killing
notting, does this problem still exist?
Dunno, it's one of those things I haven't had time to investigate if xinetd
shows the same behavior.
I originally posted the bug, but am no longer able to test to see if it still
exists. This is because I have written from scratch a whole replacement init
boot script system which I now use exclusively on all my servers (under more
than one distribution). Ironically, this bug was the trigger that got me to
develop the new scripts, although I had been wanting to condense the separate
directories for each run level into a single directory (run levels coded into
file names much like sequence numbers are) for a few months before that.
As much as I can tell about the original problem is that network interfaces were
being shut down before some services (SSH in particular) that had connections
still active. It was some kind of sequence issue, but changing sequence numbers
kept encountering other issues (but I no longer remember enough about it to tell
you what they were).
Unless someone can verify this right now, I'd just suggest closing it as
non-reproducible in the current version. To verify, login as root via SSH and
do halt or reboot and see if the SSH connection cleanly drops. If not, you've
reproduced it. If it drops cleanly, I'd say you can close this one.
Bug 3159 has been closed from request of original bug reporter. I could not
duplicate some of the problems reported in the bug, but didnt have the resources
to try all of it.