On 4/28/20 10:33, Philipp Richter wrote:
Hello,
I was wondering if it's normal that systemd inside a container is in a degraded state with systemd-logind not being able to start.
$ journalctl -b -a Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace> Apr 28 14:05:13 824304d0fa93 systemd[1]: Starting Permit User Sessions... Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: Failed to apply hostname restrictions: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: Failed at step SECCOMP spawning /usr/lib/systemd/systemd-logind: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=228/SECCOMP Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Failed with result 'exit-code'. Apr 28 14:05:13 824304d0fa93 systemd[1]: Failed to start Login Service. Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 1. Apr 28 14:05:13 824304d0fa93 systemd[1]: Stopped Login Service. Apr 28 14:05:13 824304d0fa93 systemd[1]: Condition check resulted in Load Kernel Module drm being skipped. Apr 28 14:05:13 824304d0fa93 systemd[1]: Starting Login Service... Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace> Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: Failed to apply hostname restrictions: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: Failed at step SECCOMP spawning /usr/lib/systemd/systemd-logind: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=228/SECCOMP Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Failed with result 'exit-code'. Apr 28 14:05:13 824304d0fa93 systemd[1]: Failed to start Login Service.
Then $ systemctl status gives :
● 824304d0fa93 State: degraded Jobs: 0 queued Failed: 1 units Since: Tue 2020-04-28 14:05:11 UTC; 23min ago CGroup: / ├─crun-exec │ ├─43 bash │ ├─70 systemctl status │ └─71 less ├─init.scope │ └─1 /sbin/init └─system.slice ├─systemd-journald.service │ └─15 /usr/lib/systemd/systemd-journald └─dbus.service └─26 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
I am starting a custom archlinux base image like this :
$ sudo podman run -d --cap-add=NET_ADMIN localhost/popsulfr/archlinux-base /sbin/init
The output of podman info :
host: arch: arm64 buildahVersion: 1.14.8 cgroupVersion: v2 conmon: package: Unknown path: /usr/bin/conmon version: 'conmon version 2.0.15, commit: 1bddbf7051a973f4a4fecf06faa0c48e82f1e9e1' cpus: 4 distribution: distribution: archarm version: unknown eventLogger: journald hostname: rock64 idMappings: gidmap: null uidmap: null kernel: 5.6.7-1-ARCH memFree: 3530731520 memTotal: 4097687552 ociRuntime: name: crun package: Unknown path: /usr/bin/crun version: |- crun version 0.13 commit: e79e4de4ac16da0ce48777afb72c6241de870525 spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL os: linux rootless: false slirp4netns: executable: "" package: "" version: "" swapFree: 0 swapTotal: 0 uptime: 29m 39.39s registries: search: - docker.io - registry.fedoraproject.org - quay.io - registry.access.redhat.com - registry.centos.org store: configFile: /etc/containers/storage.conf containerStore: number: 1 paused: 0 running: 1 stopped: 0 graphDriverName: overlay graphOptions: overlay.mountopt: nodev graphRoot: /var/lib/containers/storage graphStatus: Backing Filesystem: btrfs Native Overlay Diff: "true" Supports d_type: "true" Using metacopy: "false" imageStore: number: 1 runRoot: /var/run/containers/storage volumePath: /var/lib/containers/storage/volumes
Best Regards, Philipp Richter _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I think it depends on the way the systemd inside of the container is setup to run. I am surprised you need to run the systemd container with --cap-add NET_ADMIN. I would figure this is not necessary unless you want systemd inside of the container to modify the host kernels network? There are going to be some functions that systemd will be blocked, but you can loosen the security if you want these to function. Systemd is smart enough to figure out that it is running in a container and will modify the way it runs based on this. For example it will see that it does not have CAP_SYS_ADMIN and will not attempt to mount.