5

Title says it all. but here is the scenario:

  1. Connected to work via VPN
  2. on a Linux client
  3. ssh root@server.company.com

  4. init 1

Will going down to "single user mode" via "init 1" kill and disconnect my root ssh session?

Community
  • 1
Heston Holtmann
  • 163
  • 1
  • 6

4 Answers4

8

Yes, yes it will. Most services don't run in runlevel 1.

rodjek
  • 3,297
  • 16
  • 14
3

It should be OK. Whilst the SSH listener daemon is stopped in runlevel 1 on most distros, existing connections should stay up, and networking shouldn't be affected. I wouldn't be doing it without having some sort of remote console connected, though -- you never know when a rogue solar flare is going to come along and drop your network connections for juuuuust long enough to kill your SSH session.

EDIT: Some testing indicates that, on Debian systems at least, /etc/rc1.d/S30killprocs will take down existing SSH connections (because it's killing off everything). I would be inclined to knobble that script temporarily and do it's job by hand (avoiding the SSH connections) if I were to try to do what you want to do. I'd still prefer to use a remote console, though.

womble
  • 95,029
  • 29
  • 173
  • 228
  • I'm under the impression that S30killprocs only kills "user processes".. and NOT deamon services???.. – Heston Holtmann Dec 22 '09 at 05:50
  • I can confirm that /etc/rc1.d/K??sshd -> /etc/init.d/sshd.sh existed on this particular and would KILL my remote ssh session if i did a "init 1". – Heston Holtmann Dec 22 '09 at 05:52
  • 1
    An existing SSH connection would likely count as a "user process", not a "service daemon", but my killprocs has no logic in it to distinguish between the two anyway. As far as your second comment goes, as I wrote in my answer, "Whilst the SSH listener daemon is stopped [...] existing connections should stay up". You can test this by running `/etc/init.d/ssh stop` from SSH, and noting that your SSH session does not drop. This is by design, as otherwise remote upgrades would be an overly exciting experience. – womble Dec 22 '09 at 06:52
2

Sorry to bring up after such a long time. I needed answer to this same question. Current answers are wrong for my box. My findings are for Centos 5.11 based install.

  1. The reason ssh client gets disconnected is because init 1 does something like service network stop. What I observe is that and all network interfaces go down and get unconfigured. ip a and ifconfig -a confirm this.

  2. init 1 stops sshd listener process. It does not stop sshd child process that holds the session for the connected client. The ssh session eventually gets dropped due to TCP timeout because network goes down, ssh session does not get killed. If I bring the network back up service network start at the console quickly enough then my clients remain connected even though the box is at runlevel 1.

  3. Question mentions VPN. If the VPN server you are going though is on the box where you doing init 1 then yes, you normally will get disconnected because VPN server by default will NOT run at runlevel 1.

My work around to take system to runlevel 1 without losing ssh sessions, is to temporarily configure required services to continue running at run level 1. All based on Centos 5.11. YMMV. Disclaimer: I would not want to rely on this to work.

    # keep network interfaces up
    chkconfig --level 1 network on
    # if you are connecting though VPN e.g. OpenVPN running on same server
    chkconfig --level 1 openvpn on
    # While at it, might as well keep SSHD running, so you can reconnect
    chkconfig --level 1 sshd on

    init 1
    # look for messages that indicate that run level has been reached
    tail -F /var/log/messages
    # Aug 31 14:21:19 pabx-demo kernel: Kernel logging (proc) stopped.
    # Aug 31 14:21:19 pabx-demo kernel: Kernel log daemon terminating.
    # Aug 31 14:21:20 pabx-demo exiting on signal 15

That's it. This allows me to take box to init 1 remotely while remaining in control.

After you are done don't forget to undo the changes:

chkconfig --level 1 network off
chkconfig --level 1 openvpn off
chkconfig --level 1 sshd off
AnyDev
  • 121
  • 4
1

/etc/init.d/ssh stop stopped ssh without killing my existing ssh session, but init 1 did...

jscott
  • 24,204
  • 8
  • 77
  • 99