We hit what appears to be the same failure on a Ubuntu 26.04 AD-joined client at 06:41 on June 2nd, same version transition, same sss_atomic_read_s() failed symptom. After some investigation, I think there may be two things that together could explain the inconsistent behavior in this thread, though I'd welcome correction from anyone with deeper packaging knowledge.
Our /var/log/dpkg.log shows that sssd-common's postinst appears to have triggered a service restart while several sssd packages were still in half-installed state: 2026-06-02 06:41:21 status half-installed sssd-common:amd64 2.12.0-1ubuntu5 ... (sssd restarted here, mid-upgrade) ... 2026-06-02 06:41:31 status installed sssd-common:amd64 2.12.0-1ubuntu5.1 2026-06-02 06:41:38 status installed sssd-ad:amd64 2.12.0-1ubuntu5.1 Comparing the postinst scripts, on 24.04 the restart uses deb-systemd-invoke which I understand defers the restart until the full dpkg transaction completes, while on 26.04 it uses invoke-rc.d --skip-systemd-native which appears to fire immediately. I'm not certain whether this difference is intentional or whether it originated in Debian packaging. Looking at the Debian changelog, the setcap calls that grant ldap_child its cap_dac_read_search=p capability appear to be in the same postinst that triggers the restart. If that's the case, when sssd restarts mid-upgrade, the new ldap_child binary might be on disk, but without its capabilities yet set. This could mean it genuinely cannot read a root:root 0600 keytab, rather than this being a timing coincidence. If this theory is correct, it might explain a few things from this thread: why ldap_child.log was completely empty on our system (suggesting the process failed very early), why root:sssd 0640 as a workaround appeared to help (group-readable would bypass the need for the capability), and why a fresh-join test environment worked fine (capabilities were in place before sssd ever started). On our system, sssd remained down until it was manually restarted. This appears to be because Restart=on-abnormal in the service unit does not retry on a clean exit 1, which is what the sssd monitor produces when it gives up on a critical domain backend. In our case, sudo systemctl start sssd after the upgrade completed was sufficient — no keytab permission changes were needed. I'm happy to gather any additional diagnostic information if it would help narrow this down. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2155002 Title: Update to SSSD 2.12.0-1ubuntu5 breaks AD join due to SSSD inability to read keytab To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2155002/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
