1:46 p.m.
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.