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.

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 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.