Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> On Tue, 2015-05-12 at 10:49 +1000, Matt Black wrote:
>> Interesting. The important thing here then is my question - WHY does
>> libpam-systemd make a difference in some cases?
> I think Russ mentioned it before already,... it may be simply some
> timing issues i.e. libpam-systemd's presence slowing the shutdown
> somehow down a bit, and thus your sessions get properly killed.
Nope, I haven't mentioned anything about this, and I'm not sure why
libpam-systemd would make a difference.
For your explanation to be the case, that would mean there's some race,
but I'm not sure what that race would be in my model of how the system
shutdown works. Do you think that killall is racing the kernel shutting
down the network device, maybe? I wouldn't have expected that.
There have been LOTS of words written on this bug report, but having
skimmed through it again, I think some really basic information is still
missing.
What, *exactly*, is the sequence of process operations on the server that
causes the client to get a clean shutdown? What, *exactly*, is the
sequence of process operations on the server that causes the connection to
apparently hang?
It's really hard to design a solution to this problem until one has a good
answer to those two questions, and I haven't seen that information on this
thread yet. I suspect it's going to require some manual experimentation
with attempting to duplicate the shutdown behavior in a controlled way.
Clearly something changed in systemd vs. sysvinit, which is a clue, but I
don't think we've yet established *what* changed, and therefore have no
idea whether it's intentional, a side effect of something else, a bug, a
race condition, or something else we haven't anticipated.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: