Bug 1841139 - Running systemd in container results in failing systemd-logind.service
Summary: Running systemd in container results in failing systemd-logind.service
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-28 13:12 UTC by Jan Pazdziora
Modified: 2020-10-14 14:09 UTC (History)
9 users (show)

Fixed In Version: systemd-245.5-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-14 14:09:26 UTC
Type: Bug


Attachments (Terms of Use)

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).


Note You need to log in before you can comment on or make changes to this bug.