You are not logged in.
For the purpose of testing Ansible roles specific to Archlinux I'm trying to setup rootless containers with systemd/init as the process for my roles' targets, since I also want to test service management with Ansible.
I've read documentation for podman and there should be possibility for this scenario with systemd as init being the container process run. I did manage to get it working with RHEL based containers on ubi9-init images.
However, my problem is that in the case of the archlinux container it will start degraded with D-Bus, systemd-resolved and firstboot services failing. This prohibits me to do service management testing that depend on D-Bus (e.g. firewalld).
$ podman run -d --rm --name arch-init docker.io/archlinux:latest /sbin/init
48d638b4159aeb46d120126df450312420aa6d1e900ddd49f32d7fd7c975ee8f
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
48d638b4159a docker.io/library/archlinux:latest /sbin/init 5 seconds ago Up 6 seconds arch-init
$ podman exec arch-init systemctl status
● 48d638b4159a
State: degraded
Units: 231 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 4 units
Since: Wed 2024-08-14 15:03:14 UTC; 30s ago
systemd: 256.4-1-arch
CGroup: /
├─init.scope
│ ├─ 1 /sbin/init
│ └─109 systemctl status
└─system.slice
├─systemd-journald.service
│ └─18 /usr/lib/systemd/systemd-journald
├─systemd-logind.service
│ └─82 /usr/lib/systemd/systemd-logind
├─systemd-nsresourced.service
│ ├─24 /usr/lib/systemd/systemd-nsresourced
│ ├─30 systemd-nsresourcework
│ ├─31 systemd-nsresourcework
│ ├─32 systemd-nsresourcework
│ ├─33 systemd-nsresourcework
│ └─34 systemd-nsresourcework
└─systemd-userdbd.service
├─25 /usr/lib/systemd/systemd-userdbd
├─35 "systemd-userwork: waiting..."
├─36 "systemd-userwork: waiting..."
└─37 "systemd-userwork: waiting..."
$ podman exec arch-init systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● dbus-broker.service loaded failed failed D-Bus System Message Bus
● systemd-firstboot.service loaded failed failed First Boot Wizard
● systemd-resolved.service loaded failed failed Network Name Resolution
● dbus.socket loaded failed failed D-Bus System Message Bus Socket
Legend: LOAD → Reflects whether the unit definition was properly loaded.
ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
SUB → The low-level unit activation state, values depend on unit type.
4 loaded units listed.Regarding the status of the failed services:
D-Bus:
$ podman exec arch-init systemctl status dbus-broker
× dbus-broker.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; disabled; preset: disabled)
Active: failed (Result: exit-code) since Wed 2024-08-14 15:03:15 UTC; 9min ago
Duration: 2ms
Invocation: 265f5260e7074806a9bfe529134babea
TriggeredBy: × dbus.socket
Docs: man:dbus-broker-launch(1)
Process: 101 ExecStart=/usr/bin/dbus-broker-launch --scope system --audit (code=exited, status=1/FAILURE)
Main PID: 101 (code=exited, status=1/FAILURE)
Aug 14 15:03:15 48d638b4159a dbus-broker-launch[101]: launcher_add_services @ ../dbus-broker-36/src/launch/launcher.c +805
Aug 14 15:03:15 48d638b4159a dbus-broker-launch[101]: launcher_run @ ../dbus-broker-36/src/launch/launcher.c +1416
Aug 14 15:03:15 48d638b4159a dbus-broker-launch[101]: run @ ../dbus-broker-36/src/launch/main.c +152
Aug 14 15:03:15 48d638b4159a dbus-broker-launch[101]: main @ ../dbus-broker-36/src/launch/main.c +178
Aug 14 15:03:15 48d638b4159a dbus-broker-launch[101]: Exiting due to fatal error: -107
Aug 14 15:03:15 48d638b4159a systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE
Aug 14 15:03:15 48d638b4159a systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Aug 14 15:03:15 48d638b4159a systemd[1]: dbus-broker.service: Start request repeated too quickly.
Aug 14 15:03:15 48d638b4159a systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start D-Bus System Message Bus.systemd-resolved:
$ podman exec arch-init systemctl status systemd-resolved
× systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2024-08-14 15:03:15 UTC; 10min ago
Invocation: 307a7249e9f64a49aa5a29fec2f9430a
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
https://systemd.io/WRITING_RESOLVER_CLIENTS
Process: 72 ExecStart=/usr/lib/systemd/systemd-resolved (code=exited, status=217/USER)
Main PID: 72 (code=exited, status=217/USER)
Aug 14 15:03:15 48d638b4159a systemd[1]: systemd-resolved.service: Scheduled restart job, restart counter is at 5.
Aug 14 15:03:15 48d638b4159a systemd[1]: systemd-resolved.service: Start request repeated too quickly.
Aug 14 15:03:15 48d638b4159a systemd[1]: systemd-resolved.service: Failed with result 'exit-code'.
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.More error logging of the failing services:
$ podman exec arch-init journalctl -p 3
Aug 14 15:03:15 48d638b4159a systemd-nsresourced[24]: bpf-lsm not supported, can't lock down user namespace.
Aug 14 15:03:15 48d638b4159a (irstboot)[51]: systemd-firstboot.service: Failed to set up standard input: No such file or directory
Aug 14 15:03:15 48d638b4159a (irstboot)[51]: systemd-firstboot.service: Failed at step STDIN spawning systemd-firstboot: No such file or directory
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start First Boot Wizard.
Aug 14 15:03:15 48d638b4159a (resolved)[53]: systemd-resolved.service: Failed to keep CAP_SYS_ADMIN: Operation not permitted
Aug 14 15:03:15 48d638b4159a (resolved)[53]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: Operation not permitted
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a (resolved)[58]: systemd-resolved.service: Failed to keep CAP_SYS_ADMIN: Operation not permitted
Aug 14 15:03:15 48d638b4159a (resolved)[58]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: Operation not permitted
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a (resolved)[64]: systemd-resolved.service: Failed to keep CAP_SYS_ADMIN: Operation not permitted
Aug 14 15:03:15 48d638b4159a (resolved)[64]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: Operation not permitted
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a (resolved)[68]: systemd-resolved.service: Failed to keep CAP_SYS_ADMIN: Operation not permitted
Aug 14 15:03:15 48d638b4159a (resolved)[68]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: Operation not permitted
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a (resolved)[72]: systemd-resolved.service: Failed to keep CAP_SYS_ADMIN: Operation not permitted
Aug 14 15:03:15 48d638b4159a (resolved)[72]: systemd-resolved.service: Failed at step USER spawning /usr/lib/systemd/systemd-resolved: Operation not permitted
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start Network Name Resolution.
Aug 14 15:03:15 48d638b4159a systemd[1]: Failed to start D-Bus System Message Bus.From these outputs, can it be concluded that the error is with systemd-resolved needing CAP_SYS_ADMIN? It seems though that DNS resolving is working in the container.
I did find a relatable issue regarding D-Bus not working in a rootless podman container, where the problem was regarding subuid/subgid setup:
https://github.com/containers/podman/issues/22001
However, I think I do have a correct subuid/subgid setup:
$ cat /etc/subuid
user:100000:65536
root:1000000:1000000000
$ cat /etc/subgid
user:100000:65536
root:1000000:1000000000I'm not that experienced with containers yet (or educated on systemd-resolved), so therefore the question: is what I want to achieve possible? That is, to use a rootless archlinux container running init process for Ansible role testing including systemd service management?
Any help or pointers are appreciated. Thank you in advance!
P.S.: This is my first post (not counting the "Hi forums!" one). If you have feedback please let me know.
Edit: typos
Last edited by borrie (2024-08-15 12:36:44)
Offline