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

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 15/10/12 18:52 did gyre and gimble:
> 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?
> 
> Michal, Kay, ideas?

I brought something similar to this up many moons ago when I first
posted the (now redundant) patch relating to network home directories.

We have a psuedo service called network-auth.service. If the user
configures their system for network authentication, we simply enable
that service. It's ordered before s-u-s.service and after network.target.

It sits in the middle and does nothing, but enabling it ensures the
correct ordering of things.

This doesn't really address the ssh problem directly of course, but a
simple compromise could be that if you enable ssh server that it could
impose the same restrictions? Not an ideal solution, but at least it
would be conditional on having ssh enabled. And of course if you use
socket activation then this should come for "free" anyway.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/