Hide Forgot
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[06].d/K90network. But this leaves the network up when the kernel is halted and the kernel continues to response to pings (and undesireable situation, also). 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 further review. ------- 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 inetd doesn't.
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.