On Friday 10 October 2014 22:50:31 Christoph Anton Mitterer wrote:
> 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.

Exactly. Stop apache, nginx, mysql, postgres and tell me, how many 
children processes will be left, once you stopped it.
As ssh behaves differently and keeps the children alive, you have to 
handle it differently :-)

> 
> > 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.

What can I say. You made your point clear. If you don't want to rely on 
network.target my solution will not help you :-)
> 
> > 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. :)

systemctl stop ssh.service => all existing user sessions will stay alive
Try it. That is why I made this hack in the first place. The solution provided 
in the RedHat forum would shut down all ssh sessions and I want to keep 
at least one ssh session open to my server, when restarting sshd.

Cheers

Tom

Reply via email to