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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
