On Sun, Jul 24, 2016 at 01:38:25AM +0200, Michael Biebl wrote: > I referenced in my other reply that the network.target ordering has just > been added recently (in v230). So it is possible that previously there > was still an issue on shutdown. This is fixed now.
Do you plan to update jessie with this fix? I ask because I've had requests to make this openssh change available in jessie-backports. > Besides, there are many other reasons why you really want libpam-systemd > in combination with SSH. > You really want the user process be tracked as part of the user session, > so you can properly apply resource limits or safely kill user sessions. Sure. But non-systemd users don't need libpam-systemd at all in this case (I'm aware that there are other cases where they may do), and it's just noise for them; and in the case of a package such as openssh-server that's often installed on very minimal systems indeed, they may not previously have needed to deal with resolving libpam-systemd's dependencies. Unfortunately there's no good way to say "Depends: libpam-systemd, but only if systemd is pid 1". It's unfortunate that we don't have a good way to simply be able to assume that all systemd users have libpam-systemd installed, which is what I'd really prefer to be able to do here. > > I think I'll add a Recommends on it, but I really want > > openssh-server to be usable on very minimal systems, including those > > using other init systems, without having to deal with dependency > > strangenesses. > > Please disable the ssh-session-cleanup.service hack by default if you > don't want to remove it. Or better, ship it as an example file. Compromise proposal: how about I make it do nothing if libpam-systemd is installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd", which is probably the simplest available check without needing to deal with multiarch paths), in which case presumably the hack isn't needed? (For backports to jessie, such a check would need to be deleted, unless you plan to backport the ordering fix as requested above.) > I really don't what such service file be installed (and active) by > default on every system. People might see it and think it's actually ok > to apply such hacks. I'd be happy to add a warning comment to discourage that. The script is short enough that such a comment would be unlikely to be overlooked. -- Colin Watson [cjwat...@debian.org]
