Bug 2391237

Summary: Failing systemd units in systemd-based rawhide container
Product: [Fedora] Fedora Reporter: Jan Pazdziora <adelton>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: daan.j.demeyer, fedoraproject, lnykryn, msekleta, suraj.ghimire7, systemd-maint, yuwatana, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-11-04 13:47:23 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 2025-08-27 08:07:02 UTC
This bug was initially created as a copy of Bug #2391235

I am copying this bug because the issue may be in the base image or in the systemd unit definitions: 

Description of problem:

In the https://github.com/freeipa/freeipa-container project we build Fedora-based FreeIPA server images in https://quay.io/repository/freeipa/freeipa-server?tab=tags. The FreeIPA containers are systemd-based. As part of our tests we check the behaviour of stock systemd containers, to distinguish issues caused by the FreeIPA setup from issues in vanilla Fedora containers.

In latest registry.fedoraproject.org/fedora:rawhide with systemd installed, we observe

● systemd-logind.service        loaded failed failed User Login Management
● systemd-userdbd.service       loaded failed failed User Database Manager
● systemd-logind-varlink.socket loaded failed failed User Login Management Varlink Socket
● systemd-userdbd.socket        loaded failed failed User Database Manager Socket

Version-Release number of selected component (if applicable):

REPOSITORY                         TAG         IMAGE ID      CREATED       SIZE
registry.fedoraproject.org/fedora  rawhide     ac69f932f370  2 days ago    184 MB

with systemd 258~rc3-2.fc44 installed.

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have Dockerfile

FROM specify-image-with-from-parameter
RUN dnf install --setopt=install_weak_deps=False -y systemd
ENTRYPOINT [ "/usr/sbin/init" ]
STOPSIGNAL RTMIN+3

2. Build Fedora 42 and Fedora rawhide images with rootless podman:

   $ podman build --from registry.fedoraproject.org/fedora:42 -t localhost/fedora-init:42 .
   $ podman build --from registry.fedoraproject.org/fedora:rawhide -t localhost/fedora-init:rawhide .

3. Run Fedora 42 systemd container:

   $ podman run --rm -ti --name fedora-init-42 localhost/fedora-init:42

4. Observe in the output that all systemd units are reported with a green OK.
5. From another terminal check with

   $ podman exec fedora-init-42 systemctl list-units --failed
     UNIT LOAD ACTIVE SUB DESCRIPTION

   0 loaded units listed.

6. From that second terminal,

   $ podman rm -f fedora-init-42

7. Now repeat with the rawhide image:

   $ podman run --rm -ti --name fedora-init-rawhide localhost/fedora-init:rawhide

   Observe red [FAILED] outputs.

8. From another terminal, check with

   $ podman exec fedora-init-rawhide systemctl list-units --failed

Actual results:


$ podman exec fedora-init-rawhide systemctl list-units --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
● systemd-logind.service        loaded failed failed User Login Management
● systemd-userdbd.service       loaded failed failed User Database Manager
● systemd-logind-varlink.socket loaded failed failed User Login Management Varlink Socket
● systemd-userdbd.socket        loaded failed failed User Database Manager Socket

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

4 loaded units listed.

Expected results:

No failures.

Additional info:

I have no idea if using the normal Fedora based image and installing systemd with dnf is the recommended way of running systemd in containers these days. But it has been working fairly well for many years now, so this is a regression.

The full status output is

$ podman exec fedora-init-rawhide systemctl status --failed
× systemd-logind.service - User Login Management
     Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Wed 2025-08-27 07:30:35 UTC; 3min 17s ago
 Invocation: 73faed3a18a448ada4e9ffbd831f0ac1
TriggeredBy: × systemd-logind-varlink.socket
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             man:org.freedesktop.login1(5)
    Process: 87 ExecStart=/usr/lib/systemd/systemd-logind (code=exited, status=226/NAMESPACE)
   Main PID: 87 (code=exited, status=226/NAMESPACE)
   FD Store: 0 (limit: 768)
   Mem peak: 2M
        CPU: 35ms

Aug 27 07:30:35 576da50fa88f systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 5.
Aug 27 07:30:35 576da50fa88f systemd[1]: systemd-logind.service: Start request repeated too quickly.
Aug 27 07:30:35 576da50fa88f systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Aug 27 07:30:35 576da50fa88f systemd[1]: Failed to start systemd-logind.service - User Login Management.

× systemd-userdbd.service - User Database Manager
     Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service; indirect; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Wed 2025-08-27 07:30:34 UTC; 3min 18s ago
 Invocation: 86750d788e4941fc87a63c7727a4017f
TriggeredBy: × systemd-userdbd.socket
       Docs: man:systemd-userdbd.service(8)
    Process: 34 ExecStart=/usr/lib/systemd/systemd-userdbd (code=exited, status=226/NAMESPACE)
   Main PID: 34 (code=exited, status=226/NAMESPACE)
   Mem peak: 1.4M
        CPU: 7ms

Aug 27 07:30:34 576da50fa88f systemd[1]: Starting systemd-userdbd.service - User Database Manager...
Aug 27 07:30:34 576da50fa88f (-userdbd)[34]: systemd-userdbd.service: Failed to mount /run/systemd/mount-rootfs/proc/sys/kernel/domainname to /run/systemd/mount-rootfs/proc/sys/kernel/domainname: Permission denied
Aug 27 07:30:34 576da50fa88f (-userdbd)[34]: systemd-userdbd.service: Failed to set up mount namespacing: /proc/sys/kernel/domainname: Permission denied
Aug 27 07:30:34 576da50fa88f (-userdbd)[34]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Permission denied
Aug 27 07:30:34 576da50fa88f systemd[1]: systemd-userdbd.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 27 07:30:34 576da50fa88f systemd[1]: systemd-userdbd.service: Failed with result 'exit-code'.
Aug 27 07:30:34 576da50fa88f systemd[1]: Failed to start systemd-userdbd.service - User Database Manager.
Aug 27 07:30:34 576da50fa88f systemd[1]: systemd-userdbd.service: Start request repeated too quickly.
Aug 27 07:30:34 576da50fa88f systemd[1]: systemd-userdbd.service: Failed with result 'exit-code'.
Aug 27 07:30:34 576da50fa88f systemd[1]: Failed to start systemd-userdbd.service - User Database Manager.

× systemd-logind-varlink.socket - User Login Management Varlink Socket
     Loaded: loaded (/usr/lib/systemd/system/systemd-logind-varlink.socket; static)
     Active: failed (Result: service-start-limit-hit) since Wed 2025-08-27 07:30:35 UTC; 3min 17s ago
   Duration: 184ms
 Invocation: cd9fdd5059dd461e985bbb091d86e183
   Triggers: ● systemd-logind.service
       Docs: man:systemd-logind.service(8)
     Listen: /run/systemd/io.systemd.Login (Stream)

Aug 27 07:30:34 576da50fa88f systemd[1]: Listening on systemd-logind-varlink.socket - User Login Management Varlink Socket.
Aug 27 07:30:35 576da50fa88f systemd[1]: systemd-logind-varlink.socket: Failed with result 'service-start-limit-hit'.

× systemd-userdbd.socket - User Database Manager Socket
     Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.socket; enabled; preset: enabled)
     Active: failed (Result: service-start-limit-hit) since Wed 2025-08-27 07:30:34 UTC; 3min 18s ago
   Duration: 212ms
 Invocation: 796ae84870f64c2c8cfd22030b2f6c4e
   Triggers: ● systemd-userdbd.service
       Docs: man:systemd-userdbd.service(8)
     Listen: /run/systemd/userdb/io.systemd.Multiplexer (Stream)

Aug 27 07:30:34 576da50fa88f systemd[1]: systemd-userdbd.socket: Failed with result 'service-start-limit-hit'.
Notice: journal has been rotated since unit was started, output may be incomplete.

Comment 1 Jan Pazdziora 2025-10-06 06:05:24 UTC
Problem is still present with systemd-258-1.fc44.x86_64 in Fedora rawhide.

Comment 2 Jan Pazdziora 2025-10-30 05:46:38 UTC
The bug is now present on now-released Fedora 43 as well:

$ podman exec fedora-init-43 systemctl list-units --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
● systemd-logind.service        loaded failed failed User Login Management
● systemd-userdbd.service       loaded failed failed User Database Manager
● systemd-logind-varlink.socket loaded failed failed User Login Management Varlink Socket
● systemd-userdbd.socket        loaded failed failed User Database Manager Socket

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

4 loaded units listed.

Comment 3 Jan Pazdziora 2025-10-31 15:55:21 UTC
I might add that the issue is not present when this rootless systemd-based container is podman-run as --privileged.

But that is obviously not a way we'd recommend users to run the containers, and it was not necessary for many years now.

Comment 4 Zbigniew Jędrzejewski-Szmek 2025-11-04 13:47:23 UTC
I'll close this as duplicate of the other one. Having all those bugs open is just confusing.

*** This bug has been marked as a duplicate of bug 2391343 ***

Comment 5 Jan Pazdziora 2025-11-04 13:57:38 UTC
Are you sure that the root cause is the same and they are indeed the same issue?

Comment 6 Zbigniew Jędrzejewski-Szmek 2025-11-05 08:31:41 UTC

*** This bug has been marked as a duplicate of bug 2391235 ***