On Sun, 2014-12-14 at 09:28 -0800, Russ Allbery wrote: > since I routinely see the same behavior > when shutting down servers right now, in wheezy, using sysvinit. This is quite interesting, btw,... cause I've never seen that during times I've sysvinit. Have you had any special modifications that could explain that? > and Christoph's proposed fix > *would* have been a regression, which is why I spoke up just to defend my > own interests. :) Well I don't like calling my fix (and it was just one of the proposals) a regression. It would be simply a different behaviour. I simply think, that now when we anyway "massively" change the init-system, it would be a good opportunity to re-consider what we actually want. That was the sole idea of my proposal: I that we should ask ourselfs what should (all and not just ssh) services do, when they're stopped. > If the problem can be resolved without regressing, > that would be a clear improvement and I'm all in favor of that. Whether > it's important enough to go into the next release is, fundamentally, the > call of the release managers, not any of the peanut gallery debating it on > this thread. And, of course, we need a fix first before we can even talk > about whether it can go into the release. I'm a bit unsure whether it's that important or not. But since I'm experiencing that issue, it happens very often to me, that I log on back to my server, and things like aptitude give me locking errors, because an old process is still running - my ssh is configured to timeout after 2min[0],... but even then this is always quite annoying. > Given that this bothers you, I'd love to see a fix, since I don't like > seeing people running into undesired behavior! I'm just not sure how best > to fix it. The best idea that I can think of is a separate unit that > doesn't run on upgrades but that runs on shutdown prior to the network > being shut down and kills all the ssh child processes. I'd probably agree, at least in the likely case, that not general "stop behaviour" for all services will be introduced which is defined to also stop the sessions. Such unit should perhaps be called "ssh-sessions" and it would be nice if one could use it generally top stop all running ssh-sessions. As such it would of course need sshd to be stopped already. And the whole thing should be implemented for sysvinit as well :) > Note, on a point you made in one of your other messages, that I don't > think systemd can use cgroups to cleanly shut this down because systemd > explicitly uses KillMode=process for sshd precisely to avoid killing the > child processes. One needs to use one KillMode on a regular shutdown and > a different one when shutting down the system, which is what makes this > tricky. Even then when you change the KillMode,.. would that change anything? Cause AFAIR, ssh sessions run in their own new cgroups. Cheers, Chris. [0] Though I've experienced at least one case, where it remained living for at least 20mins... maybe a bug in ssh.. :/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature