SIGHUP fails to restart (3.6.1p2 -> 3.7p1)

Phil Howard phil-openssh-unix-dev at ipal.net
Wed Sep 17 06:30:54 EST 2003


I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have
more than one daemon with separate executable images).  After upgrading from
3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing
over the existing image), I do SIGHUP and get this message logged:

Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting.
Sep 16 15:07:36 vega sshd_22[22552]: RESTART FAILED: av[0]='/sbin/sshd_22', error: Bad address.

Relevant source code looks like:

=============================================================================
/*
 * Called from the main program after receiving SIGHUP.
 * Restarts the server.
 */
static void
sighup_restart(void)
{
        logit("Received SIGHUP; restarting.");
        close_listen_socks();
        close_startup_pipes();
        execv(saved_argv[0], saved_argv);
        logit("RESTART FAILED: av[0]='%.100s', error: %.100s.", saved_argv[0],
            strerror(errno));
        exit(1);
}
=============================================================================

The process is now gone.  After coming back in via my backdoor port (still on
sshd version 3.6.1p2 ... now you can see why I run separate images), I find
I can simply restart the port 22 instance and now it works fine.

So I repeat the SIGHUP, this time with 3.7p1 running, which will as shown in
the source code above, re-run the same executable path, which this time is
the same image file as it is currently running.  This time it works OK.

So for yet another test, I make a copy of the executable image, and mv the
new copy in place of the one that is running.  So now it's a different inode
to be run than is running, although the images are identical.  This also runs
OK.

1. So what's the deal?
2. Was 3.6.1p2 broken in that respect?
3. Make a saved arg after av[0] was invalid?
4. Is there some weird sensitivity to a version change?
5. What is the "correct" way to upgrade a _remote_ machine (and not get locked
   out in the process)?

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------




More information about the openssh-unix-dev mailing list