[arch-general] How to reboot remotely without hanging ssh session?
Guys, I remote administer one arch server and after moving to systemd I haven't found a way to reboot without hanging the ssh session. Prior to system, we could simply pass the shutdown command via ssh and the ssh session would complete/close before reboot took place: i.e. $ ssh remote.host.org "sudo shutdown -r now" However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs. Is there a better way to reboot a remote server and avoid this? -- David C. Rankin, J.D.,P.E.
On Wed, 05 Feb 2014 13:19:56 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Guys,
I remote administer one arch server and after moving to systemd I haven't found a way to reboot without hanging the ssh session. Prior to system, we could simply pass the shutdown command via ssh and the ssh session would complete/close before reboot took place: i.e.
$ ssh remote.host.org "sudo shutdown -r now"
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
Is there a better way to reboot a remote server and avoid this?
AFAIU, this issue is related to the lack of ordering between systemd-user-sessions.service and network.target (the former should start after the latter)... OTOH, one can simply $ ssh root@remote.host.org and do # ( sleep 30 && systemctl reboot ) & # exit Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, Am 05.02.2014 20:19, schrieb David C. Rankin:
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
you probably want to follow the following discussion(s): - https://bugs.archlinux.org/task/31250 - https://bbs.archlinux.org/viewtopic.php?pid=1166093 So, this is actually known and there seems to be no "clean" solution. Best regards, Karol Babioch
I don't see why you can't just run: shutdown -r 30 Is it so urgent that the system be rebooted 'now?' On Wed, Feb 5, 2014 at 3:01 PM, Karol Babioch <karol@babioch.de> wrote:
Hi,
Am 05.02.2014 20:19, schrieb David C. Rankin:
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
you probably want to follow the following discussion(s):
- https://bugs.archlinux.org/task/31250 - https://bbs.archlinux.org/viewtopic.php?pid=1166093
So, this is actually known and there seems to be no "clean" solution.
Best regards, Karol Babioch
-- - Vincent Schumaker
On Thu, Feb 6, 2014 at 5:03 AM, Vincent Schumaker <vschum@gmail.com> wrote:
I don't see why you can't just run:
shutdown -r 30
Is it so urgent that the system be rebooted 'now?'
I agree, why not just use `$ shutdown -r [+1]`? That'll make the command exit cleanly and give you a minute to end the SSH session. And at least on my Arch machine, /usr/bin/shutdown is a symlink to /usr/bin/systemctl so I suppose that it actually uses systemd under the hood.
On Wed, Feb 05, 2014 at 09:01:09PM +0100, Karol Babioch wrote:
Am 05.02.2014 20:19, schrieb David C. Rankin:
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
you probably want to follow the following discussion(s):
- https://bugs.archlinux.org/task/31250 - https://bbs.archlinux.org/viewtopic.php?pid=1166093
So, this is actually known and there seems to be no "clean" solution.
I had the same problem with remote poweroff some months ago. The solution I used was to create a delayed systemd target. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Although this isn't really solution you could simply terminate the ssh connection after running ``systemctl reboot`` by pressing the escape character ('~' by default) and then '.' (see "ESCAPE CHARACTERS" in ``man ssh``). If you know ssh is going to hang, exiting is just two keystrokes away. I know it's not ideal but its good enough for me. On 5 February 2014 20:05, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Wed, Feb 05, 2014 at 09:01:09PM +0100, Karol Babioch wrote:
Am 05.02.2014 20:19, schrieb David C. Rankin:
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
you probably want to follow the following discussion(s):
- https://bugs.archlinux.org/task/31250 - https://bbs.archlinux.org/viewtopic.php?pid=1166093
So, this is actually known and there seems to be no "clean" solution.
I had the same problem with remote poweroff some months ago. The solution I used was to create a delayed systemd target.
Ciao,
-- FA
A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Wed, Feb 5, 2014 at 12:05 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
I had the same problem with remote poweroff some months ago. The solution I used was to create a delayed systemd target.
That's exactly what I ended up doing as well when building Arch virtual machines for Vagrant [1]. [1] https://github.com/elasticdog/packer-arch/commit/6f747f94258b35f74c4fccb11c0... -- Aaron Bull Schaefer
On 02/06/2014 09:43 AM, Aaron Bull Schaefer wrote:
On Wed, Feb 5, 2014 at 12:05 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
I had the same problem with remote poweroff some months ago. The solution I used was to create a delayed systemd target.
That's exactly what I ended up doing as well when building Arch virtual machines for Vagrant [1].
[1] https://github.com/elasticdog/packer-arch/commit/6f747f94258b35f74c4fccb11c0...
Thanks for everyone's response. All good points, there isn't any need for an immediate reboot, and my point wasn't to complain about the behavior. As I try and make friends with systemd, I like to learn why things do what they do. The poweroff.timer solution is attractive and I like the (subshell) approach (fast, simple and readily available after kernel updates). I don't pretend to understand all the nitty-gritty that plays into difficulty ironing out ordering between systemd-user-sessions.service and network.target processing, but slowly the basics are sinking in. -- David C. Rankin, J.D.,P.E.
On Fri, Feb 7, 2014 at 1:47 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Thanks for everyone's response.
All good points, there isn't any need for an immediate reboot, and my point wasn't to complain about the behavior. As I try and make friends with systemd, I like to learn why things do what they do. The poweroff.timer solution is attractive and I like the (subshell) approach (fast, simple and readily available after kernel updates). I don't pretend to understand all the nitty-gritty that plays into difficulty ironing out ordering between systemd-user-sessions.service and network.target processing, but slowly the basics are sinking in.
The session shutdown logic got a lot of fixes in systemd git, especially today. I'd expect this to work properly in systemd 209.
On 05.02.2014 20:19, David C. Rankin wrote:
Guys,
I remote administer one arch server and after moving to systemd I haven't found a way to reboot without hanging the ssh session. Prior to system, we could simply pass the shutdown command via ssh and the ssh session would complete/close before reboot took place: i.e.
$ ssh remote.host.org "sudo shutdown -r now"
However with systemd, using "systemctl reboot" the ssh session hangs until the remote host reboot or a timeout occurs.
Is there a better way to reboot a remote server and avoid this?
I'm using the following line: $ su -c "systemctl --no-block reboot" && exit I enter my password, then I instantly see the broadcast message telling me that the system is going down and the ssh session gets closed. If you started the session as root, this line should do: # systemctl --no-block reboot && exit I didn't try it, because root login is disabled on my machines. Regards, Robert. -- GnuPG-Key: EDC67BBA Fingerprint: D5F0 BC03 3F6D 521C 6F2D 40C8 DDBA 25D9 EDC6 7BBA
participants (10)
-
Aaron Bull Schaefer
-
David C. Rankin
-
Delcypher
-
Emil Lundberg
-
Fons Adriaensen
-
Jan Alexander Steffens
-
Karol Babioch
-
Leonid Isaev
-
Robert Knauer
-
Vincent Schumaker