On Fri, 2014-10-10 at 18:51 +0200, Tom Hutter wrote: > > Hmm I'm a bit torn apart between thinking that this is either an > > ugly hack or a clean solution ^^ > Never said it's not a hack. I may disagree in the word "ugly" ;-) ;-) > If ssh is restarted, my hack does exactly the expected. The ssh user > sessions stay alive. Only, if the network is shut down, the sessions > will be terminated. Looking at this excerpt from systemd.special(7), I > would say, my hack does exactly the expected. Sure,... I never claimed it wouldn't work... just that I'm not sure whether I like the idea of having a separate unit file for the ssh "sessions". I mean you have a similar concepts in many other daemons (like httpd or some DB servers have their open connections)... and none of them will have these managed via a separate unit file. > network.target > This unit is supposed to indicate when network functionality is > available, but it is only very weakly defined what that is supposed Well that's another point,.. I personally really hate the idea of network.target... as even upstream admits it's weakly defined... and I think this brings all kinds of problem with it. What does "indicate when network functionality is available" really mean in a even driven world with many possible network connections per computer and services networking depends upon. So the problem is that many things may hook into network.target or network-pre.target,... starting from just the bare question whether a device is up or not, over things like "do we have DNS?" to stuff like firewalls, or VPN. Of course this doesn't directly affect us, I just want to point out that depending on network.target always means some serialisation point, which is IMHO against the ideas of systemd. At least from my (though non-expert PoV) I'd suggest to avoid dependencies on it when possible. > As mentioned above, restarting of sshd will not shut down the existing > ssh sessions. Security flaw or not. Well you're talking about restarting the sshd process - sure it won't kill the existing sessions. I was referring to restarting the ssh[d] service (i.e. systemd service)... and was generally questioning, what do we want to happen, when people restart respectively stop it. :) > If you want to stop the ssh sessions during shutdown and signalling it > to the clients, you have to have the network stack still available. > Therefore killing all ssh sessions before network.target is going down > seems to me the last possible moment. Otherwise the ssh sessions will > be closed but your client will not be signalled, which was the reason > I made this hack. Again here,.. my point (b) was more a general question, not only specific to shutdown. My idea was: When we'd agree that stopping the ssh service (not restarting/reloading) should actually also stop the connections, then one could AFAIU simply do something like this: Remove the "KillMode=process" line from the ssh.service unit file. Or is KillMode also used on systemd's restart/reload of services? > I think it's more a philosophical question, if running processes > depending on the network should survive a network restart - I would > say: No I'd say: depends Many services just happily survive a network restart... ssh is a good example (unless sshd kills the connection beacause of TCP ClientAlive or SSH ClientAlive). > Then again if you say "Yes", I think it's hard to find a solution, to > terminate the ssh sessions only on network stop and not on network > restart. Well all this question wouldn't arise when there was no separate service, right? If the normal ssh.service would just kill existing connections, than, AFAIU, the only thing needed is: After=networking.target (which we have anyway) and removal of: KillMode=process If network is just restarted, then this shouldn't affect ssh.service at all. But if the machine is shut down, then systemd should stop ssh.service, thereby calling the default KillMode=control-group. And because of the After= it should happen before networking.target is "stopped". Or do I miss something? > If I am correct, restart in systemd means stop and start. So how > distinguish between stop to shut down an stop to restart? Mhhh... that would be a problem though in my idea,.. cause I base my assumption that on restart KillMode=control-group wouldn't happen. :/ Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature