Description of problem: With systemd-245.5-2.fc33.x86_64 in Fedora rawhide, running systemd in container results in degraded state, with systemd-logind.service failing to start. Version-Release number of selected component (if applicable): systemd-245.5-2.fc33.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have Dockerfile FROM registry.fedoraproject.org/fedora:rawhide # Due to https://pagure.io/fedora-kickstarts/pull-request/645 we now have to # install systemd explicitly RUN dnf install -y systemd ENTRYPOINT [ "/usr/sbin/init" ] 2. Build container image: podman build -t systemd . 3. Run the container: podman run --name=systemd --rm -ti systemd /usr/sbin/init 4. Observe the output to be [ OK ] Reached target Sockets. [ OK ] Reached target Basic System. Starting Home Area Manager... Starting Login Service... Starting Permit User Sessions... [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. [ OK ] Stopped Login Service. Starting Login Service... [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. [ OK ] Stopped Login Service. Starting Login Service... [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. [ OK ] Stopped Login Service. Starting Login Service... [ OK ] Finished Permit User Sessions. [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. [ OK ] Stopped Login Service. Starting Login Service... [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. [ OK ] Stopped Login Service. [FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details. Starting D-Bus System Message Bus... [ OK ] Started D-Bus System Message Bus. [ OK ] Started Home Area Manager. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. 5. In different terminal, check the journal: podman exec systemd journalctl | grep -i login Actual results: May 28 13:10:39 2965e0a0b318 systemd[1]: Starting Login Service... May 28 13:10:39 2965e0a0b318 systemd[26]: systemd-logind.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace setup. May 28 13:10:39 2965e0a0b318 systemd[26]: systemd-logind.service: Failed to apply hostname restrictions: Permission denied May 28 13:10:39 2965e0a0b318 systemd[26]: systemd-logind.service: Failed at step SECCOMP spawning /usr/lib/systemd/systemd-logind: Permission denied May 28 13:10:39 2965e0a0b318 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=228/SECCOMP May 28 13:10:39 2965e0a0b318 systemd[1]: systemd-logind.service: Failed with result 'exit-code'. May 28 13:10:39 2965e0a0b318 systemd[1]: Failed to start Login Service. May 28 13:10:39 2965e0a0b318 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 1. May 28 13:10:39 2965e0a0b318 systemd[1]: Stopped Login Service. Expected results: No failures. Additional info: This is in rootless podman container, on Fedora 32 with podman-1.9.2-1.fc32.x86_64.
This is a regression in the sense that before, fedora-container-base.ks in https://pagure.io/fedora-kickstarts/ did systemctl mask systemd-remount-fs.service dev-hugepages.mount sys-fs-fuse-connections.mount systemd-logind.service getty.target console-getty.service It no longer does so, so it's really up to those units to protects themselves if they cannot run in containers, or to some presets to correctly not enable those units.
This is the commit that removed these services from Fedora 32: https://pagure.io/fedora-kickstarts/c/57e13a1b8970c2e15d0c310aa871e4737781a23f?branch=f32
I filed https://pagure.io/releng/issue/9603 about this problem in stable container releases.
(In reply to Jan Pazdziora from comment #1) > It no longer does so, so it's really up to those units to protects > themselves if they cannot run in containers, or to some presets to correctly > not enable those units. I don't think there's anything to fix on systemd side. systemd-logind.service works fine in containers, as long as the container environment provides adequate permissions. If there's something specific in the rootless podman container setup that prevents systemd from starting the unit, then we can work on resolving this, but this will have to be driven by the maintainers of that container env. Maybe additional privileges need to be given by the container maintainer, or maybe the container images for that environment need to provide dropins for the unit to disable some protections, or maybe some other solution is appropriate. I don't know enough about podman to resolve this.
Today with registry.fedoraproject.org/fedora:rawhide = bd0f684e7cbc and systemd-246-1.fc33.x86_64 installed into the container, the bug seems no longer present. What has changed?
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
I think this was fixed in https://github.com/systemd/systemd/commit/daf8f72b4e (v246, v245.5).