SPUG: Closing HTTP::Daemon port

[Andrew Sweger]

I was able to repeat the behavior you describe on a Debian 3.0 (woody)
system. Very nice code, easy to read and follow (even with braces where I
don't like them). Thanks.

First I'd like to say that this is a strange way to recycle a server. This
is what I would call "in-band" control where the control is excerted over
the same channel that the daemon normally operates through. Most programs
will use an out-of-band control method either through signals or Unix
sockets (e.g., postfix, named).

Just a very brief skim over the code and playing, I came across this odd
bit of code:

while (my $page = get("http://localhost:$port/quit"))
    {
    logInfo("  Server Killed");
    sleep 1;    # otherwise we occasionally try to start too fast
    }

The get() is being called by the second instance of the script which does
indeed kill the first. But note that get() returns the requested document
(which may be "true" or "false" depending on what was returned). get()
returns undef in the event of a failure.

What struck me is that should get() return anything true, it will report
"Server Killed", sleep, and then call get() *again*. But I don't see the
message "Server Killed" reported by the second instance. Why would you
keep calling get() if it got a true result back?

On the network side of things, what I am seeing is a socket created by the
second instance (by the get() call I presume) that hangs around for a
minute in TIME_WAIT state. It's on the daemon's side of the connection
(the first instance). So, I'm going to say that it is your daemon that's
not cleaning up the socket after handling incoming requests. I can prove
this by calling for arbitrary URIs on this port (repeatedly) and see
half-dead sockets piling up on the daemons side. E.g., "wget
http://localhost:9876/foobar". The TIME_WAIT sockets are not associated
with any process. If I remembered more about the TIME_WAIT state, I'd know
what this means. But I'm guessing that the daemon is releasing the socket
before completely shutting it down after handling the request.

I'll try to take a closer look at this portion of the code later. In the
meantime, consider a more traditional out-of-band control system. This is
useful in the event that your daemon is having trouble with it's http
interface (and keeps rogues from shutting down your server).

On Mon, 11 Aug 2003, Marc M. Adkins wrote:

> OK, here's a stripped-down version.  It demonstrates the behavior on
> Mandrake 9.1.

-- 
Andrew B. Sweger -- The great thing about multitasking is that several
                                things can go wrong at once.