On Mon, Oct 15, 2012 at 10:52 AM, Lennart Poettering <[email protected]> wrote: > On Sun, 14.10.12 13:18, Tom Gundersen ([email protected]) wrote: > >> It is necessary to terminate remote sessions before shutting down >> the network connection. Otherwise, remote sessions might hang. >> >> In particular this is a problem with ssh on Arch [0]. The network >> connection might be pulled down before the ssh sessions are terminated. >> Moreover, shutting down the sshd daemon does not (and should not) >> terminate the corresponding ssh sessions, so ordering ssh itself >> After=network.target is not sufficient. > >> >> Cc: [email protected] >> >> [0]: <https://bugs.archlinux.org/task/31250> >> --- >> >> This patch is only an RFC and not meant for inclusion as is. The reason >> is that we would like to order the shutdown of user sessions befor the >> shutdown of the network. However, also ordering the start of user >> sessions after the start of the network is unnecessary, and with >> NetworkManager being as slow as it is on startup this will slow down >> boot considerably in the common case. >> >> I see two options: split user-sessions into local-user-sessions and >> remote-user-sessions and order only the latter After=network.target, or >> introduce a new StopBefore= dependency and use that in user-sessions. >> >> Comments? > > > Hmm, yeah, I am a too bit afraid of delaying local logins at boot until > after the network is up. I wonder if we can find a different > solution. Maybe we should hook this to nss-user-lookup.target instead? > Or maybe indeed split s-u-s.service into two?
Given that we're testing local user sessions that finish starting up ~ 2 seconds and the network isn't up until ~ 5 seconds, having them delayed that much isn't grokkable for us. I'm a bit partial to saying "sorry, network is something you can't rely on", but if there is a solution to shutting down remote sessions before shutting down networking then I'm welcome to that, as it will at least have a chance of signalling "remote host disconnected" to remote clients instead of timing out. Cheers, Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
