1 |
Grant wrote: |
2 |
> I just upgraded ssh and when I try to restart I get: |
3 |
> |
4 |
> * Stopping sshd ... [ !! ] |
5 |
> |
6 |
> I don't see anything about it in '/var/log/sshd/current'. How can I |
7 |
> figure out what is wrong? I'm a little nervous because I don't want |
8 |
> to shut myself out of this remote server. |
9 |
> |
10 |
|
11 |
I had a similar issue after a previous update to ssh when I went to |
12 |
restart it to get it to use the new binaries. One of the nice features |
13 |
of sshd is that your current session will say active even if you kill |
14 |
the sshd daemon process. Of course, if you get disconnected then you |
15 |
will not be able to log back in, so it's good to do what you need to |
16 |
quickly if you do need to kill (or if it's really stuck, kill -9) the |
17 |
process. When I had this problem I issued a `kill -9 PID_NUMBER && |
18 |
/etc/init.d/sshd start` - just be *sure* that you're killing the |
19 |
/usr/sbin/sshd process and not one of your sshd login forks at the same |
20 |
time. |
21 |
|
22 |
Alex Schuster wrote: |
23 |
> If you think the upgrade is necessary and don't want to wait until you or |
24 |
> s.o. else has physical access in case sshd doesn't come up again, you |
25 |
> could |
26 |
> try to restart sshd manually by issuing a "kill -SIGHUP $( pidof sshd )". |
27 |
|
28 |
|
29 |
I don't recommend doing this as it will also kill your current ssh |
30 |
session. If for some reason the SIGHUP doesn't take correctly on the |
31 |
listening daemon you will find yourself locked and kicked out of the |
32 |
server. Use top or htop to determine the actual PID of the daemon only. |
33 |
|
34 |
-- |
35 |
Josh |