Josh Cepek writes:
> I had a similar issue after a previous update to ssh when I went to
> restart it to get it to use the new binaries. One of the nice features
> of sshd is that your current session will say active even if you kill
> the sshd daemon process. Of course, if you get disconnected then you
> will not be able to log back in, so it's good to do what you need to
> quickly if you do need to kill (or if it's really stuck, kill -9) the
> process. When I had this problem I issued a `kill -9 PID_NUMBER &&
> /etc/init.d/sshd start` - just be *sure* that you're killing the
> /usr/sbin/sshd process and not one of your sshd login forks at the same
> time.
>
> Alex Schuster wrote:
> > If you think the upgrade is necessary and don't want to wait until you
> > or s.o. else has physical access in case sshd doesn't come up again,
> > you could
> > try to restart sshd manually by issuing a "kill -SIGHUP $( pidof sshd
> > )".
>
> I don't recommend doing this as it will also kill your current ssh
> session. If for some reason the SIGHUP doesn't take correctly on the
> listening daemon you will find yourself locked and kicked out of the
> server. Use top or htop to determine the actual PID of the daemon only.
Oh, whoops! Big mistake, you are right - sorry for that, this was bad
advice. I did not think about these other sshd processes. Thanks for being
watchful and pointing this out.
Still, I would prefer -HUP instead of -9, as this would make the sshd server
restart itself. Just in case /etc/init.d/sshd start also makes trouble - it
really shouldn't, but neither should /etc/init.d/sshd stop.
Alex
--
[EMAIL PROTECTED] mailing list
