Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 3159

Summary:	TCP connections not properly closed at shutdown/reboot
Product:	[Retired] Red Hat Linux	Reporter:	phil
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	rvokal
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-24 17:56:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description phil 1999-05-30 19:30:53 UTC

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.

Comment 1 David Lawrence 1999-06-01 22:55:59 UTC

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.

Comment 2 rjb 1999-09-01 17:05:59 UTC

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.

Comment 3 Brent Fox 2002-06-05 01:03:43 UTC

notting, does this problem still exist?

Comment 4 Bill Nottingham 2002-06-05 01:33:57 UTC

Dunno, it's one of those things I haven't had time to investigate if xinetd
shows the same behavior.

Comment 5 phil 2002-06-05 01:46:50 UTC

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.

Comment 6 Stephen John Smoogen 2003-01-24 17:56:32 UTC

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.