[systemd-devel] [RFC][PATCH]user-sessions: order after network.target

[Kok, Auke-jan H]

On Mon, Oct 15, 2012 at 10:52 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sun, 14.10.12 13:18, Tom Gundersen (teg at jklm.no) 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: bisson at archlinux.org
>>
>> [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