You are not logged in.
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/systemdbut 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/systemdor 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 directoryThis 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)
Offline
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.
Offline
Just out of curiosity: what is your use-case for running systemd itself containerized? Instead of running multiple containerized applications/processes?
Offline
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 :-(
Offline
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?
Offline
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.
Offline