[systemd-devel] Possible race condition for setting cgroup sticky bit

[Anders Olofsson]

> > To introduce systemd in our system, we've started with just wrapping rc
> and all the old initscripts so we can get systemd running first and then
> afterwards start converting to native services.
> > The boot is basically two services: legacy_rcS.service (which runs
> "/etc/init.d/rc S") and legacy_rc3.service (which runs "/etc/init.d/rc 3").
> There is also a legacy_rc4.service (wanted by upgrade.target) used for
> firmware upgrads and similar special system actions.
> > Journal, udev and syslog runs as separate services outside these wrappers
> and the idea is to migrate boot script to services a few at a time until the
> legacy wrappers are empty and can be dropped.
> 
> Ah, that's the issue. You can't really do manipulations like that in
> systemd's own hierarchy: sticking multiple services in the same cgroup
> in the name=systemd hierarchy will break things heavily (and I am
> surprised you didn't run into that pronlem earlier). It is OK to stick
> muliple services into the same group on all other hierachies, but not in
> systemd's own. In fact, you shouldn't really fiddle with systemd private
> hierachy at all. We need that to keep track of our own service state
> (i.e. for checking whether a service is still running), we will use it
> to kill services and so on, we take the liberty to remove groups in that
> hierarchy as we see fit... and for that we need to keep the groups
> separate.
> 
> This is actually documented in the man pages:
> 
> "It is not recommended to manipulate the service control group path in
> the systemd named hierarchy." (see systemd.exec(5) the part about
> ControlGroup=)
> 
> I have now changed the man page to be a bit stronger here, and say that
> you might get undefined behaviour if you change systemd's own hierarchy.
> 
> >
> > When looking in sysfs, I see cgroups for all the legacy services, even though
> the rcS and rc3 services use the configured generic cgroup:
> > The following is from a working system, when a failure happens, rc and rcS
> are present, but not rc3:
> > # ls -d /sys/fs/cgroup/systemd/system/legacy*
> > /sys/fs/cgroup/systemd/system/legacy_rc.service
> > /sys/fs/cgroup/systemd/system/legacy_rc3.service
> > /sys/fs/cgroup/systemd/system/legacy_rcS.service
> >
> > This was what I meant with "cgroups for all services" exist even
> > though it has been overridden.  Without the ControlGroup= setting,
> > legacy_rc3 and legacy_rcS would have use the cgroups with the same
> > names. But since we've specify that we want a different name, I'm
> > wondering why I still see the default names that we don't want to use.
> 
> Well, the systemd hiearchy is special. We have special semantics for it,
> and you shouldn't alter it. You are free to rearrange cgroups in all
> other hierarchies and drop as many services in the same cgroup as you
> wish for those, but not for systemd's own name=systemd hierarchy.
> 
> I hope this makes sense,

Yes, thank you for your help.

A follow up question. Is there some other way to accomplish what we were trying to do here?

The reason for doing this the we have a remote shell (e.g. telnet) that runs as separate services (socket activation) and if  a user (or an automated test) logs in and (re)starts a daemon that still belongs to the legacy blob, it will end up running in the telnet group instead of in the legacy group where it is supposed to be. When the client disconnects, either the daemon will be killed or if KillMode=none is set the process will run but still belong to the cgroup from an old telnet session.
Is there a way to have the telnet sessions run as part of the legacy group instead?

/Anders