Systemctl also has a direct path to systemd through a private Unix socket if there's no dbus-daemon. But if you see zombie processes, that suggests systemd has most likely crashed during the post-upgrade "daemon-reexec" (which loads the new systemd pid1 in place of the old one). When that happens, systemd freezes to avoid kernel-panic'ing the whole system. Check your dmesg and journalctl.
On Fri, May 15, 2026, 12:50 Windl, Ulrich <[email protected]> wrote: > Hi! > > > > I’ve upgraded multiple systems from SLES15 SP6 to SP7 without a problem, > but one machine is terriblx slow since that. > > The symptom is something related to Dbus I guess, because: > > > > # systemctl status sshd.service > > Failed to get properties: Transport endpoint is not connected > > > > The timeout is rather exactly 90s. > > > > # ps aux |grep dbus > > message+ 1071 0.0 0.0 0 0 ? Zs May12 0:00 > [dbus-daemon] <defunct> > > root 3763 0.0 0.0 0 0 ? Z May12 0:00 > [dbus-daemon] <defunct> > > root 6707 0.0 0.0 0 0 pts/1 Z 09:11 0:00 > [dbus-daemon] <defunct> > > windl 6968 0.0 0.1 19804 2704 pts/2 S 09:24 0:00 > dbus-launch --autolaunch 17ec11b8a2f93cbaa951878d4ddd0b29 --binary-syntax > --close-stderr > > windl 6969 0.0 0.1 32076 3352 ? Ss 09:24 0:00 > /usr/bin/dbus-daemon --syslog-only --fork --print-pid 7 --print-address 9 > --session > > root 8424 0.0 0.1 4168 2304 pts/1 S+ 11:25 0:00 grep > --color=auto dbus > > windl 10329 0.0 0.0 0 0 ? Z May13 0:00 > [dbus-launch] <defunct> > > windl 10330 0.0 0.0 0 0 ? Zs May13 0:00 > [dbus-daemon] <defunct> > > root 10454 0.0 0.0 0 0 ? Z May13 0:00 > [dbus-daemon] <defunct> > > root 10543 0.0 0.0 0 0 ? Z May13 0:00 > [dbus-launch] <defunct> > > root 10544 0.0 0.0 0 0 ? Zs May13 0:00 > [dbus-daemon] <defunct> > > > > Those “defunct” processes are children of PID 1, e.g.: > > # ps -o pid,ppid,cmd -p 10544 > > PID PPID CMD > > 10544 1 [dbus-daemon] <defunct> > > > > # rpm -q systemd dbus-1 > > systemd-254.27-150600.4.62.1.x86_64 > > dbus-1-1.12.2-150400.18.8.1.x86_64 > > > > The interesting thing is that the versions of systemd and dbus were the > same before and after upgrade; the only differences I found were: > > REL (grub2-systemd-sleep-plugin-2.12) 150600.8.52.1 --> 150700.19.29.1 > (noarch) > > VER (util-linux-systemd) 2.39.3-150600.4.21.1 --> 2.40.4-150700.4.10.1 > (x86_64) > > > > (meaning: for grub2-systemd-sleep-plugin the release changes, while for > util-linux-systemd the version had changed) > > > > In the journal I only see things like this: > > May 12 15:20:01 v04 dbus-daemon[1071]: [system] Activating via systemd: > service name='org.opensuse.Snapper' unit='snapperd.service' requested by > ':1.21' (uid=0 pid=6141 comm="/usr/bin/snapper list-configs ") > > May 12 15:20:26 v04 dbus-daemon[1071]: [system] Failed to activate service > 'org.opensuse.Snapper': timed out (service_start_timeout=25000ms) > > May 12 15:20:26 v04 dbus-daemon[1071]: [system] Activating via systemd: > service name='org.opensuse.Snapper' unit='snapperd.service' requested by > ':1.22' (uid=0 pid=6191 comm="snapper --table-style 0 list-configs ") > > May 12 15:20:51 v04 dbus-daemon[1071]: [system] Failed to activate service > 'org.opensuse.Snapper': timed out (service_start_timeout=25000ms) > > May 12 15:24:07 v04 systemd-logind[1588]: Failed to start session scope > session-4.scope: Connection timed out > > May 12 15:24:07 v04 sshd[6230]: pam_systemd(sshd:session): Failed to > create session: Connection timed out > > > > I had opened a support case for SLES already (without solution so far) and > I had a session with an AI chatbot (Claude Haiku 4.5) that really had no > good idea; the recommendation was to roll-back to SP6. The conclusion was: > > > > 1. Systemd 254 is identical between SP6 and SP7 > > 2. dbus-daemon binary hasn't changed > > 3. util-linux-systemd changed from 2.39.3 to 2.40.4 - major version bump > > 4. dbus-daemon is hanging on activating org.freedesktop.locale1 service > with a 25-second timeout > > 5. systemd is unable to reap the defunct dbus processes (parent is PID 1) > > 6. After killall -9, new defunct processes spawn immediately > > 7. systemctl commands themselves hang/timeout at 90 seconds > > 8. No kernel messages or hung tasks > > 9. rpm -V util-linux-systemd shows no file integrity issues > > 10. No recent dmesg output > > > > The fact that systemctl commands hang for exactly 90 seconds before > failing with "Transport endpoint is not connected" suggests: > > - systemctl is trying to connect to dbus > > - dbus socket exists but is not responding > > - After 90 seconds (which might be 1m30s rounding to 90s in some > contexts), the timeout kicks in > > > > Any ideas? > > > > Regards, > > Ulrich > > > > > > > > Kind regards, > > Ulrich Windl > > >
