I am surprised you need to run the systemd container with

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(a)lists.podman.io > To unsubscribe send an email to podman-leave(a)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. _______________________________________________ Podman mailing list -- podman(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io