At what point are cgroups initialized for systemd?

Question

So to cut a long story short, I am trying to get systemd working with an Arch install, but without running systemd from init. This means I am booting into a system that is not running systemd, then trying to start systemd on it.

The problem I am facing relates to cgroups - during startup, systemd complains about missing /sys/fs/cgroup/systemd as a cgroup, and so runs with reduced functionality as it thinks cgroups are unavailable. This causes problems with any tools that use D-Bus to communicate with systemd.

Running systemd normally (running as PID 1) the cgroups are created properly and systemd works to its fully. However when it is run on an already booted system, no cgroups are created. What I want to know is at what point during the init process is /sys/fs/cgroup/systemd created/mounted, and how can I replicate that on an already running system? I can confirm that it is not /sbin/init that creates the cgroup, as running that instead yields the same results.

Failing that, where should I start looking in the source code of systemd? Or perhaps there is a mailing list where I might get better answers directly from the developers?

Solution

Right, so after a bit of digging around in the source code of systemd, I have found the point at which the systemd cgroup is created. In src/core/main.c within main() the function mount_setup_early() is called, but only if systemd is running as PID 1 and not in a container. mount_setup_early() is defined in src/core/mount-setup.c, and simply mounts certain essential filesystems such as /proc, /dev and more importantly /sys/fs/cgroup/systemd.

The fact that I was trying to run systemd as PID != 1 meant that this function was never executed. So, further down in main() test_cgroups() is executed, and fails since /sys/fs/cgroup/systemd is not mounted. Since there is no way to spoof this process' PID (or at least, not one that I know of or am willing to try), the solution is to manually mount these filesystems before executing systemd. At least, that is the theory.

Another interesting side-effect of this adventure is a bit more understanding in how named hierarchies work with cgroups. There is little documentation available for cgroups, especially on how exactly named hierarchies work. To mount a named hierarchy in a similar fashion to how systemd does it, run:

mount -t cgroup cgroup -o none,name=<name> <mountpoint>

This gives you a completely blank hierarchy similar to the name=systemd hierarchy mounted on /sys/fs/cgroup/systemd. If you want to bind subsystems to that hierarchy, replace none with the subsystems you want.

Comments

[Xenopathic]

Yes, I know I probably shouldn't be trying to get systemd working along with another init system, but it would be really interesting if I could get it to work, and fixing the broken bits is a good challenge. cgroups are a mystery to me though.