>> I've also found that installing libpam-systemd seems to fix this for >> me in my testing. (If I discover it still to be a problem, I'll post >> again). However, I'd like to understand why libpam-systemd makes a >> difference if anyone has any insight? > > It doesn't, I still have the problem occasionally on multiple systems, > all with libpam-systemd installed. > It's pure coincidence.
Interesting. The important thing here then is my question - WHY does libpam-systemd make a difference in some cases? >> Finally, there are issues with using the ssh.socket approach which are >> not at first apparent. When exiting an SSH session, all processes >> created under that session are terminated - which means tools like >> screen and tmux will not work. This may or may not be a problem for >> you, but it's certainly means ssh.socket is also not a drop-in >> replacement like ssh.service. > > please open a separate bug for this. IMO this isn't a bug, it's intended behaviour of ssh.socket. On 12 May 2015 at 10:45, Christoph Anton Mitterer <cales...@scientia.net> wrote: > > On Tue, 2015-05-12 at 10:20 +1000, Matt Black wrote: > > I've also found that installing libpam-systemd seems to fix this for > > me in my testing. (If I discover it still to be a problem, I'll post > > again). However, I'd like to understand why libpam-systemd makes a > > difference if anyone has any insight? > It doesn't, I still have the problem occasionally on multiple systems, > all with libpam-systemd installed. > It's pure coincidence. > > > Finally, there are issues with using the ssh.socket approach which are > > not at first apparent. When exiting an SSH session, all processes > > created under that session are terminated - which means tools like > > screen and tmux will not work. This may or may not be a problem for > > you, but it's certainly means ssh.socket is also not a drop-in > > replacement like ssh.service. > please open a separate bug for this. > > > Cheers. > Chris >
