Discussion item here: https://discussion.fedoraproject.org/t/systemd-error-in-f41/136011 Receive when running dnf5 update: Running trigger-install scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Finished trigger-install scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> Failed to connect to bus: Broken pipe >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.7-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to start jobs: Transport endpoint is not connected >>> Complete! Reproducible: Always Steps to Reproduce: This has been happening whenever systemd has been updated since installation of F41. Did not occur in F40. Attaching: (‘journalctl -b --no-hostname’).
Created attachment 2056534 [details] ‘journalctl -b --no-hostname’
I can confirm this issue still occurs. I have the same issue on two f41 workstations.... [250/250] Removing flatpak-kcm-0:6.2.3- 100% | 2.0 B/s | 55.0 B | 00m20s >>> Running trigger-install scriptlet: systemd-0:256.8-1.fc41.x86_64c41.x86_64h >>> Finished trigger-install scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> Failed to start jobs: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_6486_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64c41.x >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to start jobs: Transport endpoint is not connected >>> Complete!
I'm seeing the same issue. dnf5 update, workstation >>> Running trigger-install scriptlet: systemd-0:256.8-1.fc41.x86_64c41.x86_64h >>> Finished trigger-install scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> Failed to start jobs: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_6486_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64c41.x >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.8-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> Complete!
I'm changing affected component to dnf5. My apologies to the dnf folks if this is not their issue. Please reassign to who you believe would be the correct component.
Those are outputs of failed RPM scriptlets. In this case triggers packaged by systemd <https://src.fedoraproject.org/rpms/systemd/blob/f41/f/triggers.systemd>. Unless there is a bug DNF5, it means the systemd scriptlet failed. Printing an output of failed scriptlets is a news of dnf5-5.2.6.0. That's why you see it since Fedora 41, where also dnf5 replaced dnf-4. Maybe you had the problem previously, but you could not see it. It would be great if you were able to find out what installed or updated package triggers it. For me upgrading systemd in Fedora 41 does not reproduce it. It looks like D-Bus or systemd session died, or the bus client is denied to access the bus. It could be a bug in systemd, D-Bus, SELinux policy. Maybe a wrong order of updating the packages. Moving it to distribution as DNF5 is only a messenger here.
(In reply to Petr Pisar from comment #5) > ... > Moving it to distribution as DNF5 is only a messenger here. Thanks Petr!
I don't think anyone here watching distribution will be able to do much. ;) Lets punt over to systemd and perhaps they have some ideas on how to track it down?
I've also been experiencing this on multiple machines since they were upgraded to F41 via dnf system-upgrade: >>> Running trigger-install scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Finished trigger-install scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Scriptlet output: >>> Reload daemon failed: Transport endpoint is not connected >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.10-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to start jobs: Transport endpoint is not connected >>> Complete!
Also on a dnf system-upgrade system: >>> Running trigger-post-uninstall scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> >>> Running trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Finished trigger-install scriptlet: systemd-0:256.11-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> Failed to connect to user scope bus via machine transport: No medium found >>> Complete!
Standalone reproducer: # run0 systemd-run -t sh -x /usr/lib/systemd/systemd-update-helper user-reexec The error is triggered by `systemctl --user -M 0@ daemon-reexec`.
I am also still seeing this on F41.
I'm seeing this regularly on F42 now - each time systemd gets updated. In my case it has two failing phases / scriptlets: 1) trigger-install phase: >>> Running trigger-install scriptlet: systemd-0:257.5-6.fc42.x86_64 >>> Finished trigger-install scriptlet: systemd-0:257.5-6.fc42.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe (SIGPIPE) 2) trigger post-install phase: >>> Running trigger-post-uninstall scriptlet: systemd-0:257.5-6.fc42.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:257.5-6.fc42.x86_64 >>> Scriptlet output: >>> Failed to start jobs: Communication endpoint not connected
I've got this issue with fc41. It wasn't apparent immediately after upgrade from fc40, but started a few days back. This sequence occured after a very small update not apparently involving system d. dnf update Updating and loading repositories: Fedora 41 - x86_64 - Updates 100% | 105.1 KiB/s | 25.5 KiB | 00m00s Fedora 41 - x86_64 - Updates 100% | 1.9 MiB/s | 3.1 MiB | 00m02s Repositories loaded. Package Arch Version Repository Size Upgrading: libupnp x86_64 1.14.22-1.fc41 updates 265.0 KiB replacing libupnp x86_64 1.14.20-1.fc41 fedora 269.0 KiB python3-boto3 noarch 1.38.28-1.fc41 updates 2.2 MiB replacing python3-boto3 noarch 1.38.23-1.fc41 updates 2.1 MiB python3-botocore noarch 1.38.28-1.fc41 updates 101.6 MiB replacing python3-botocore noarch 1.38.23-1.fc41 updates 101.5 MiB upower x86_64 1.90.9-4.fc41 updates 280.1 KiB replacing upower x86_64 1.90.9-1.fc41 updates 528.6 KiB upower-libs x86_64 1.90.9-4.fc41 updates 174.7 KiB replacing upower-libs x86_64 1.90.9-1.fc41 updates 174.7 KiB xdg-desktop-portal x86_64 1.20.3-1.fc41 updates 1.8 MiB replacing xdg-desktop-portal x86_64 1.20.0-2.fc41 updates 1.8 MiB Transaction Summary: Upgrading: 6 packages Replacing: 6 packages Total size of inbound packages is 9 MiB. Need to download 9 MiB. After this operation, 108 KiB will be freed (install 106 MiB, remove 106 MiB). Is this ok [y/N]: y [1/6] libupnp-0:1.14.22-1.fc41.x86_64 100% | 406.7 KiB/s | 111.4 KiB | 00m00s [2/6] upower-0:1.90.9-4.fc41.x86_64 100% | 1.1 MiB/s | 117.2 KiB | 00m00s [3/6] python3-boto3-0:1.38.28-1.fc41.noarch 100% | 1.0 MiB/s | 431.6 KiB | 00m00s [4/6] upower-libs-0:1.90.9-4.fc41.x86_64 100% | 782.9 KiB/s | 57.9 KiB | 00m00s [5/6] xdg-desktop-portal-0:1.20.3-1.fc41.x86_64 100% | 682.5 KiB/s | 504.4 KiB | 00m01s [6/6] python3-botocore-0:1.38.28-1.fc41.noarch 100% | 2.9 MiB/s | 7.9 MiB | 00m03s ---------------------------------------------------------------------------------------------------------------- [6/6] Total 100% | 3.1 MiB/s | 9.1 MiB | 00m03s Running transaction [ 1/14] Verify package files 100% | 52.0 B/s | 6.0 B | 00m00s [ 2/14] Prepare transaction 100% | 8.0 B/s | 12.0 B | 00m01s [ 3/14] Upgrading upower-libs-0:1.90.9-4.fc41.x86_64 100% | 621.9 KiB/s | 176.0 KiB | 00m00s [ 4/14] Upgrading python3-botocore-0:1.38.28-1.fc41.noarch 100% | 11.3 MiB/s | 102.1 MiB | 00m09s [ 5/14] Upgrading python3-boto3-0:1.38.28-1.fc41.noarch 100% | 5.0 MiB/s | 2.2 MiB | 00m00s [ 6/14] Upgrading upower-0:1.90.9-4.fc41.x86_64 100% | 370.1 KiB/s | 285.3 KiB | 00m01s [ 7/14] Upgrading xdg-desktop-portal-0:1.20.3-1.fc41.x86_64 100% | 1.0 MiB/s | 1.9 MiB | 00m02s [ 8/14] Upgrading libupnp-0:1.14.22-1.fc41.x86_64 100% | 2.3 MiB/s | 267.0 KiB | 00m00s [ 9/14] Removing python3-boto3-0:1.38.23-1.fc41.noarch 100% | 1.2 KiB/s | 187.0 B | 00m00s [10/14] Removing upower-0:1.90.9-1.fc41.x86_64 100% | 222.0 B/s | 49.0 B | 00m00s [11/14] Removing python3-botocore-0:1.38.23-1.fc41.noarch 100% | 14.9 KiB/s | 2.8 KiB | 00m00s [12/14] Removing upower-libs-0:1.90.9-1.fc41.x86_64 100% | 137.0 B/s | 8.0 B | 00m00s [13/14] Removing xdg-desktop-portal-0:1.20.0-2.fc41.x86_64 100% | 925.0 B/s | 124.0 B | 00m00s [14/14] Removing libupnp-0:1.14.20-1.fc41.x86_64 100% | 0.0 B/s | 13.0 B | 00m14s >>> Running trigger-install scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Finished trigger-install scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: Broken pipe >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.15-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to start jobs: Transport endpoint is not connected >>> Complete!
(In reply to wscg45 from comment #13) > This sequence occured after a very > small update not apparently involving system d. [...] > Upgrading: > libupnp x86_64 1.14.22-1.fc41 > updates 265.0 KiB > replacing libupnp x86_64 1.14.20-1.fc41 > fedora 269.0 KiB > python3-boto3 noarch 1.38.28-1.fc41 > updates 2.2 MiB > replacing python3-boto3 noarch 1.38.23-1.fc41 > updates 2.1 MiB > python3-botocore noarch 1.38.28-1.fc41 > updates 101.6 MiB > replacing python3-botocore noarch 1.38.23-1.fc41 > updates 101.5 MiB > upower x86_64 1.90.9-4.fc41 > updates 280.1 KiB > replacing upower x86_64 1.90.9-1.fc41 > updates 528.6 KiB > upower-libs x86_64 1.90.9-4.fc41 > updates 174.7 KiB > replacing upower-libs x86_64 1.90.9-1.fc41 > updates 174.7 KiB > xdg-desktop-portal x86_64 1.20.3-1.fc41 > updates 1.8 MiB > replacing xdg-desktop-portal x86_64 1.20.0-2.fc41 > updates 1.8 MiB > [...] > >>> Running trigger-install scriptlet: systemd-0:256.15-1.fc41.x86_64 > >>> Finished trigger-install scriptlet: systemd-0:256.15-1.fc41.x86_64 > >>> Scriptlet output: > >>> Failed to connect to user scope bus via machine transport: Broken pipe > >>> Failed to connect to user scope bus via machine transport: Broken pipe The update does does install new systemd, yet it executes scriptlets provided by systemd. Executing scriptlets from a foreign package is a feature of "trigger-install" type of scriptlet. In other words, systemd is still involved.
The issue seems to be caused by uninstalling GNOME Software or KDE Discover on my devices after a fresh Fedora 42 installation. Did you guys also happen to remove your GUI software managers?
> The update does does install new systemd, yet it executes scriptlets > provided by systemd. Executing scriptlets from a foreign package is a > feature of "trigger-install" type of scriptlet. In other words, systemd is > still involved. Yeah, I realized that since my original misleading post (sorry). I have a working theory that the systemd scriptlet might be somehow trying to connect to a wrong "user scope bus" (root instead of a logged in user in my case). I was using a root shell (su) for dnf updates before, switched to a (probably more common) sudo now and no error messages so far, but it's still just a small number of runs. Would be nice if the error message actually identified the bus it's trying to connect to.
(In reply to Farid Zellipour from comment #15) > The issue seems to be caused by uninstalling GNOME Software or KDE Discover > on my devices after a fresh Fedora 42 installation. Did you guys also happen > to remove your GUI software managers? No GNOME Software on my system, but I have KDE Discover installed (and running fine now - it had some issues on F40), but not a fresh install (this system goes way,way back and went through many updates). Speaking of which I have another (fresher) system which started maybe around F39 (currently on F42 as well), and I don't remember seeing this issue there. Then again, the new one was installed from a KDE spin, the older one was a regular Fedora release used with various alternative WMs/DEs and then later switched to KDE Plasma (Wayland), so you might be up to something there.
(In reply to fedy from comment #16) > I have a working theory that the systemd scriptlet might be somehow trying > to connect to a wrong "user scope bus" (root instead of a logged in user in > my case). I was using a root shell (su) for dnf updates before, switched to > a (probably more common) sudo now and no error messages so far, but it's > still just a small number of runs. Looks like I might be right there. Did some system maintenance & stumbled upon a way to replicate the error using dnf reinstall. [Fedora 42] Running: dnf reinstall tumbler - from a root shell (su) - triggers the error every time While: sudo dnf reinstall tumbler - this works just fine with no errors
I have no idea how systemd detects the user bus. Try comparing environment variables, SELinux context of the running shell and cgroup of the running shell. I hope you invoke su with --login option.
(In reply to Petr Pisar from comment #19) > I hope you invoke su with --login option. I do not. If I'm not mistaken, there could be potentially multiple user buses running simultaneously (for example multiple logged-in users with GUI sessions running on the same system). So if the systemd uses the environment to identify them I would consider that a bug - It should enumerate and iterate over all of the running user sessions.
From the su man page: > Note that on systemd-based systems, a new > session may be defined as a real entry point > to the system. However, su does not create a > real session (by PAM) from this point of view. > You need to use tools like systemd-run or > machinectl to initiate a complete, real session. Can you try "systemd-run -t dnf upgrade"?
(In reply to Joseph D. Wagner from comment #21) > From the su man page: > > > Note that on systemd-based systems, a new > > session may be defined as a real entry point > > to the system. However, su does not create a > > real session (by PAM) from this point of view. > > You need to use tools like systemd-run or > > machinectl to initiate a complete, real session. > > Can you try "systemd-run -t dnf upgrade"? I haven't tried that yet, but using sudo instead of su as discussed comment #16 and comment #18 does appear to circumvent the issue. Would you consider this a bug or a feature?
> Would you consider this a bug or a feature? I'm not part of the upstream (neither dnf nor dbus), so I don't know. I am just trying to help isolate the problem. It *seems* like the broken pipes are caused by su not setting up the full environment that dnf is expecting. However, I don't know if upstream considers this a) an oversight that needs to be fixed, or b) a design feature of systemd-based systems that should be using "systemd-run -t" instead. I defer to those closer to upstream and more experienced with this sort of development.
Just in case people thought sudo is the answer, from today's dnf update of fc42.x86_64 workstation. The sudo command doesn't do the 100% correct thing either. I assume the affected rpm's were only tested with the test script run as a loggged in root and not an sudo-ed root. wolfgang@arbol:~$ sudo dnf update -y --refresh [sudo] password for wolfgang: Updating and loading repositories: ... [63/64] Removing tcpdump-14:4.99.5-3.fc 100% | 516.0 B/s | 16.0 B | 00m00s [64/64] Removing krb5-libs-0:1.21.3-5.f 100% | 5.0 B/s | 64.0 B | 00m12s >>> Running post-transaction scriptlet: passt-selinux-0:0^20250606.g754c6d7-1.fc >>> Finished post-transaction scriptlet: passt-selinux-0:0^20250606.g754c6d7-1.f >>> Scriptlet output: >>> restorecon: Could not stat /run/user/1000/doc: Permission denied. >>> restorecon: Could not stat /run/user/1000/gvfs: Permission denied. >>> Complete!
(In reply to Wolfgang Rupprecht from comment #24) > Just in case people thought sudo is the answer, from today's dnf update of > fc42.x86_64 workstation. The sudo command doesn't do the 100% correct thing > either. I assume the affected rpm's were only tested with the test script > run as a loggged in root and not an sudo-ed root. > > wolfgang@arbol:~$ sudo dnf update -y --refresh > [sudo] password for wolfgang: > Updating and loading repositories: > ... > [63/64] Removing tcpdump-14:4.99.5-3.fc 100% | 516.0 B/s | 16.0 B | > 00m00s > [64/64] Removing krb5-libs-0:1.21.3-5.f 100% | 5.0 B/s | 64.0 B | > 00m12s > >>> Running post-transaction scriptlet: passt-selinux-0:0^20250606.g754c6d7-1.fc > >>> Finished post-transaction scriptlet: passt-selinux-0:0^20250606.g754c6d7-1.f > >>> Scriptlet output: > >>> restorecon: Could not stat /run/user/1000/doc: Permission denied. > >>> restorecon: Could not stat /run/user/1000/gvfs: Permission denied. > >>> > Complete! That might be unrelated. I got the same message while logged directly into the console as root (Ctrl+Alt+F3). Also, notice the message is not "Broken pipe."