Bug 1841139

Summary: Running systemd in container results in failing systemd-logind.service
Product: [Fedora] Fedora Reporter: Jan Pazdziora <jpazdziora>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: fedoraproject, jpazdziora, lnykryn, msekleta, randy, ssahani, s, systemd-maint, zbyszek
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-245.5-1.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-14 14:09:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Pazdziora 2020-05-28 13:12:40 UTC
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.

Comment 1 Jan Pazdziora 2020-05-28 16:39:57 UTC
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.

Comment 2 Randy Barlow 2020-07-14 15:50:24 UTC
This is the commit that removed these services from Fedora 32: https://pagure.io/fedora-kickstarts/c/57e13a1b8970c2e15d0c310aa871e4737781a23f?branch=f32

Comment 3 Randy Barlow 2020-07-14 16:19:16 UTC
I filed https://pagure.io/releng/issue/9603 about this problem in stable container releases.

Comment 4 Zbigniew Jędrzejewski-Szmek 2020-07-26 14:48:16 UTC
(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.

Comment 5 Jan Pazdziora 2020-08-05 09:50:27 UTC
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?

Comment 6 Ben Cotton 2020-08-11 13:34:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 7 Zbigniew Jędrzejewski-Szmek 2020-10-14 14:09:26 UTC
I think this was fixed in https://github.com/systemd/systemd/commit/daf8f72b4e (v246, v245.5).