Problem:
After upgrading to UCS 5.2-x, certain UCS systems specifically those acting as Samba Active Directory Domain Controllers (AD-DC) may report failed systemd socket units related to the SSSD (System Security Services Daemon). Despite these error messages, no direct functional issues may be immediately noticeable. The following log entries illustrate the issue:
May 23 14:17:17 lagpdc systemd[1]: Failed to listen on sssd-nss.socket - SSSD NSS Service responder socket.
May 23 14:17:17 lagpdc systemd[1]: Failed to listen on sssd-pam.socket - SSSD PAM Service responder socket.
Using systemctl --failed
, the following services may appear as failed:
● apcupsd.service loaded failed failed UPS power management daemon
● univention-runit.service loaded failed failed LSB: Univention process supervision
● sssd-nss.socket loaded failed failed SSSD NSS Service responder socket
● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket
● sssd-pam.socket loaded failed failed SSSD PAM Service responder socket
This issue is discussed in Bug 58121 and is primarily cosmetic unless SSSD-based functionality is explicitly required. On systems where SSSD is not actively used (e.g., pure Samba AD-DC setups), the failed sockets may be safely disabled to clean up the systemd status output.
Workaround:
Disabling Unused SSSD Sockets
To suppress the error messages and clear the failed service state, follow these steps on the affected UCS system. These commands disable and mask the unused SSSD sockets and reset the SSSD service state.
1. Disable the Unused Sockets
systemctl disable sssd-nss.socket sssd-pam.socket sssd-pam-priv.socket
This will remove the symbolic links from the service wants directory:
Removed "/etc/systemd/system/sssd.service.wants/sssd-nss.socket".
Removed "/etc/systemd/system/sssd.service.wants/sssd-pam.socket".
Removed "/etc/systemd/system/sssd.service.wants/sssd-pam-priv.socket".
2. Mask the Socket Units
Prevent systemd from accidentally activating them again in the future:
systemctl mask sssd-nss.socket sssd-pam.socket sssd-pam-priv.socket
3. Restart the SSSD Service and Reset Failures
Now restart the SSSD service and clear any remaining failed unit states:
systemctl restart sssd.service
systemctl reset-failed
4. Verify System State
Ensure that no failed systemd units are left:
systemctl --failed
You should see:
0 loaded units listed.
This confirms that the system is in a clean state and no residual error messages related to SSSD sockets remain.
Conclusion
If your UCS 5.2 system is functioning as a Samba AD-DC and does not utilize SSSD for authentication or directory services, the above workaround can be safely applied. This prevents unnecessary systemd error messages without impacting the system’s intended functionality.
For long-term resolution, please monitor updates related to Bug #58121 or apply any future errata updates addressing this behavior.