7

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?

Robin McCorkell
  • 1,176

2 Answers2

9

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.

Robin McCorkell
  • 1,176
0

systemd is an init system, even if you manage to get it running as PID != 1, there surely will be many things going wrong (e.g. which init process will be responsible for starting/stopping processes?)

There are ways of using cgroups without using systemd, if that is what you need, as they are implemented in the kernel, not in systemd, which is "only" using those capabilities.

As per information from the devs, the systemd web page lists all kinds of resources, including several mailing lists, the URL of the git repository and the project documentation, which is very comprehensive.

dawud
  • 1,518