Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
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 [cjwatson@debian.org]
Reply to: