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?


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.

| improve this answer | |

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.

| improve this answer | |
  • 2
    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. – Xenopathic May 2 '13 at 7:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.