[systemd-devel] Regression in v40? User session inside a unit.
lennart at poettering.net
Mon Mar 5 10:12:48 PST 2012
On Mon, 20.02.12 01:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> Not sure if this is an intended regression or not but a user reported a
> problem to me recently which I thought was a little strange. It's maybe
> been fixed already in newer versions (we were in a beta semi-freeze and
> I've been on holiday so not updated to v43 yet but will do soon).
> Anyway the problem was the unit was run as root (no User=) but that
> ultimately ran a perl script that then invoked su to switch to the
> apache user. While this is obviously not needed (better to use
> User=apache), it did result in the user session cgroup
> (name=systemd:/user/apache/c59) overriding the unit cgroup
> (name=systemd:/system/zoneminder.service) and thus systemd could no
> longer "see" the processes the service started (and thus didn't kill
> them on systemctl stop zoneminder.service)
> If using su is all that is needed to "escape" the unit cgroup, then it
> could be a little bit ambiguous for a user trying to find all processes
> started by a given service.
> Hopefully, this has been fixed already, or perhaps documented somewhere
> I missed (I didn't see it in
> Perhaps user sessions should be kept under name=logind cgroup tree
> rather than reusing name=systemd? That would avoid the problem (although
> it could still mean that such spawed processes get killed off if some
> config options like kill-session-processes=1 are set I guess, but that
> would be the same as currently I suppose).
For killing services we generally kill everything in the cgroup plus the
main plus the control process (if there is any). We do this to avoid
problems with services which are moved to other cgroups. I guess what is
missing here is a bit of code in the service listing logic to also
include the main/control PID explicitly in the cgroup listing, if it
isn't part of the cgroup anyway.
I'll add this to the TODO list.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel