[Pkg-sysvinit-devel] Bug#769483: /usr/sbin/service restarts daemons in the current session cgroups when not running systemd

[Matteo Panella]

On 23/11/2014 19:03, Petter Reinholdtsen wrote:
> You can perhaps provide details on how this work in Wheezy, to allow
> us to understand what changed?

Sure: in Wheezy this doesn't happen at all because there is no logind
running without systemd (and by extension systemd-shim and cgmanager),
so under normal circumstances cgroups are not involved.

In Jessie this doesn't happen if either sysvinit or upstart are PID1
until libpam-systemd is pulled in through a dependency chain (almost
every desktop task, plus some daemons which depend on policykit-1 like
libvirtd).

Whenever libpam-systemd is installed, logind becomes active (through
systemd-shim and cgmanager) and every session which goes through
pam_systemd.so gets its own set of cgroups.

At this point, things start to go "wrong" when using either invoke-rc.d
or service [1]: every time a daemon is started (or restarted) through a
"logind-enabled" session either directly or as a consequence of a dpkg
action (e.g. through invoke-rc.d in the configure stage), it will
inherit the session cgroups instead of being placed into the root cgroups.

The only exception is with upstart as PID1: daemons with an upstart job
will be forked directly by PID1, so they'll end up in the root cgroup.
Daemons without a job will fall back to the initscript and thus exhibit
the same behavior (as a reference, even Ubuntu 14.04 and later got this
interaction between initscripts and systemd-shim/logind wrong).

> As far as I know, sysvinit do not have any relationship with cgroups
> at all, and thus do not quite sure understand why it now is a bug.

Truth be told, I never realized something was "wrong" until I tried to
figure out why some logind session were still lingering in the "closing"
state. At first, I thought it was a regression for #756076, then I
realized that I restarted some daemons and they were running inside the
session cgroups, thus keeping the session around in "closing" state even
though I had logged out and logged back in.

> Can you explain why you believe sysvinit should do anything about 
> cgroups at all?

Because the current implementation of service and invoke-rc.d breaks
logind session semantics: if a daemon ends up in a logind session, the
session will linger as long as the daemon keeps running.

For remote sessions, this *usually* isn't a big deal (at least, not that
I know of, I still don't know exactly what logind is supposed to do).
For local sessions (ttys and X11), though, this means that device ACLs
set by logind will not be cleared until the session is properly closed -
that is, until the "misplaced" daemons die (or are moved out of the way
by root using cgm movepidabs).

> I hope some of the more active sysvinit maintainers can look at this,
> as I really lack the time to figure out the cgroups details.

I'm afraid it will require a bit of cooperation from cgmanager
maintainers as well. The not-so-simple (but almost correct) solution
would be asking cgmanager to move service/invoke-rc.d into the root
cgroups right before calling the init script, but unfortunately the dbus
call to do that is asynchronous and would cause a race between cgmanager
moving the caller into the right cgroups and the caller forking to run
the initscript.

Also, I honestly don't know how to handle things if/when cgmanager is
being updated and thus it's not guaranteed to be restarted before other
daemons in the same dpkg run.

Again, the only reason I filed this issue is because logind uses the
cgroup lifecycle to manage device ACLs, otherwise this would be a minor
misbehavior not even worth of being reported, let alone fixed.

[1]: I'm deliberately leaving the case of root running an initscript
directly since the current draft of the init policy considers that
action as deprecated, but most importantly because it cannot be fixed
without rewriting the entire corpus of initscripts in Debian.

Regards,
-- 
Matteo Panella

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20141123/2787c6cb/attachment.sig>