[Known as broken] Running systemd unprivileged in Docker container

jernst · 2021-06-11 22:17:44

I can run a full Arch system (with systemd as PID 1) in a Docker container in Docker privileged mode:

sudo docker run -i -t --privileged archlinux /usr/lib/systemd/systemd

but privileged mode is, well, a bit privileged. I believe used to be able to tone this down with something like:

sudo docker run -i -t --cap-add=ALL -v /sys/fs/cgroup:/sys/fs/cgroup:ro archlinux /usr/lib/systemd/systemd

or even less capabilities than "all". But now I'm getting:

systemd 248.3-2-arch running in system mode. (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
Detected virtualization docker.
Detected architecture x86-64.
Detected first boot.

Welcome to Arch Linux!

Initializing machine ID from random generator.
Failed to create /init.scope control group: Read-only file system
Failed to allocate manager object: Read-only file system
[!!!!!!] Failed to allocate manager object.
Exiting PID 1...

I don't even understand what that means. (Somebody likes exclamation marks.) What's the "manager object", and who is trying to allocate it?

Assuming that the "Read-only filesystem" in question is that /sys/fs/cgroup, when binding it into the container as read-write I get that instead:

Failed to create /init.scope control group: No such file or directory
Failed to allocate manager object: No such file or directory

This long Serverfault thread may be related? Are they saying it's broken? Can it be done?

Last edited by jernst (2021-06-12 18:51:35)

jernst · 2021-06-12 18:51:11

Apparently it is broken since systemd 248, see https://github.com/moby/moby/issues/42275

The proper way, according to the systemd people, is for Docker to implement the systemd container specification, like other container managers do: https://systemd.io/CONTAINER_INTERFACE/ but that hasn't happened yet.

twelveeighty · 2021-06-13 00:14:21

Just out of curiosity: what is your use-case for running systemd itself containerized? Instead of running multiple containerized applications/processes?

jernst · 2021-06-13 00:23:19

Use case: development and testing of non-cloud (e.g. personal server) applications & installations. Much easier to throw away a container, and start again from a clean slate than to try to rescue a partially messed-up system.

Works like a charm with systemd-nspawn on btrfs with CoW. Would like the same experience on Docker :-(

twelveeighty · 2021-06-13 00:36:05

Sorry, I meant: why spawn sub-processes from a containerized "pid 1" instead of running those processes in their own, separate containers on the host/pod?

jernst · 2021-06-13 00:41:34

If what you develop / test includes the activation / deactivation / migration / ... of such services you got to do that on the system-under-test i.e. in the container, not on the host system. And yes, ideally I'd like this setup to work recursively, in case such services are actually containerized themselves.

Arch Linux

#1 2021-06-11 22:17:44

[Known as broken] Running systemd unprivileged in Docker container

#2 2021-06-12 18:51:11

Re: [Known as broken] Running systemd unprivileged in Docker container

#3 2021-06-13 00:14:21

Re: [Known as broken] Running systemd unprivileged in Docker container

#4 2021-06-13 00:23:19

Re: [Known as broken] Running systemd unprivileged in Docker container

#5 2021-06-13 00:36:05

Re: [Known as broken] Running systemd unprivileged in Docker container

#6 2021-06-13 00:41:34

Re: [Known as broken] Running systemd unprivileged in Docker container

Board footer