Re: Cant' reboot my mud.

From: Jeremy Elson (
Date: 04/22/94

>      This is not being caused by the mud code or autorun. The problem
> that you are experiencing can be caused one of two ways. The first
> and most likely is that you already have a version of the mud up
> and running and don't realize it.

Or, there is something else being run on that port which you've forgotton
about, such as a sign.

I think the second explanation (below) is more likely though.

>     The second cause of this problem can be blamed on your users. Try
> issuing the netstat command in /usr/ucb and you should see a line
> similar to this:
> tcp 0   0  YOUR_HOST_NAME.4224    ESTABLISHED
> when the mud is executing properly and you have a PC in from the UK.
> If the mud crashes or reboots you may run across this display:
> tcp 0   0  YOUR_HOST_NAME.4224    TIME_WAIT
> The TIME_WAIT is caused by the TCP/IP protocol stack. It won't allow
> you to reboot your mud because it has a lingering network connection
> that may get confused if the server port suddenly came back to life.

This isn't quite correct, though it's very close. :)  As you say, normal
connections to the MUD (or any other TCP/IP port) show up in the netstat
display as being in state ESTABLISHED.  When the server goes down, the
operating system bumps all remaining connections into the "TIME_WAIT" state
for a little while; the purpose of this is to keep another application from
immediatley reusing the port, just in case there are a few lagged packets
still heading across the Internet, expecting to find the old application

TIME_WAIT connections are normal, though, and they don't cause problems.
After about 30 to 60 seconds (depending on your operating system), the
TIME_WAIT connections will disappear.

The problem is that sometimes connections can get stuck in the CLOSING
state.  As far as I can tell, this is caused when the machine on the
other end of the line crashes (say, when someone's telnetting from a
PC and just turns the PC off).  The reason for this is that TCP uses
negotiation for both opening and closing a connection, and the port is
stuck there waiting for some element of the port-closing negotiation,
which obviously will never come from a crashed machine.

CLOSING connections are big trouble, because some operating systems will
not allow a new application to use a certain port until all of the CLOSING
connections go away.  And I've seen CLOSING connections stay around for
literally a month before.

So, what's the solution?  I don't know.  The dumb solution is just to reboot
your own machine, which will get rid of any CLOSING connections.  Or, if you
can, move to a site which uses an OS that handles CLOSING connections more

I've heard that it's possible to screw around with the networking code
(specifically, the SO_REUSEADDR parameter) to get the application to ignore
CLOSINGs, but I've never had any success with that.


This archive was generated by hypermail 2b30 : 12/07/00 PST