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

Reply via email to