On Wed, Aug 7, 2013 at 12:58 PM, Rodrigo Rivas <rodrigorivascosta@xxxxxxxxx> wrote: > On Tue, Aug 6, 2013 at 5:18 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: > >> On Tue, Aug 06, 2013 at 01:56:09PM +0100, Paul Gideon Dann wrote: >> >> > ssh -t remote1 "sudo systemctl poweroff && exit" >> > >> > Technically I guess it's a race condition, but the command should >> terminate >> > and close the SSH session before OpenSSH is shut down, so you shouldn't >> get >> > the hang. >> > >> > Alternatively, you could try "systemctl start poweroff.target" to see if >> that >> > returns quicker. I'm not sure if the poweroff command returns straight >> away >> > or waits. Basically, I'm thinking that if you can get the first command >> to >> > return quickly, your shell will close nicely before the shutdown kills >> the >> > connection. >> >> Thanks to all who suggested solutions. >> >> What difference should the '&& exit' make ? The ssh will terminate >> anyway when poweroff returns. Problem is that by then it's too >> late. >> > > That's why I suggested "systemctl --no-block poweroff". That should return > immediately and finish the ssh session well within the grace time period > that systemd gives to every service in poweroff. > > As I see it, the problem with a simple "systemctl poweroff" (or equivalent) > is not a race-condition, It is correct that systemtl poweroff is synchronous, but using telinit or --no-block will avoid that. > but a dead-lock: systemd waits for the ssh session > to finish to go on with the poweroff, and the ssh session waits for the > poweroff to finish until it returns. And those are precisely the situations > where "--no-block" is useful. Actually, you don't get this deadlock. ssh will shutdown just fine even if you have some command (such as systemctl) running. The reason for the problem you are seeing here is that the network is torn down before ssh is shutdown. This isn't actually a big problem, as the remote machine is shutting down just fine. The only problem is that the ssh client ends up hanging, which is annoying, but not really critical (kill it/ignore it/whatever). I have an idea how to solve this at the systemd/networkmanager/openssh side, but haven't gotten around to sorting all that out yet (we need to order the network tear-down after user-sessions are closed, but we don't want to order network setup before user-sessions are allowed). Cheers, Tom
