Christoph Anton Mitterer <cales...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
