** Description changed:

+ [ Impact ]
+ 
+  * An explanation of the effects of the bug on users and justification
+    for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+    explanation of how the upload fixes this bug.
+ 
+ [ Test Plan ]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package
+    fixes the problem.
+ 
+  * if other testing is appropriate to perform before landing this
+    update, this should also be described here.
+ 
+ [ Where problems could occur ]
+ 
+  * Think about what the upload changes in the software. Imagine the
+    change is wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the event
+    of a regression.
+ 
+  * This must never be "None" or "Low", or entirely an argument as to why
+    your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
+ 
+ [ Other Info ]
+ 
+  * Anything else you think is useful to include
+ 
+  * Make sure to explain any deviation from the norm, to save the SRU
+    reviewer from having to infer your reasoning, possibly incorrectly.
+    This should also help reduce review iterations, particularly when the
+    reason for the deviation is not obvious.
+ 
+  * Anticipate questions from users, SRU, +1 maintenance, security teams
+    and the Technical Board and address these questions in advance
+ 
+ [ Original Description ]
+ 
  On Ubuntu 26.04 LTS with sssd 2.12.0-1ubuntu5.2, every start of sssd_be
  leaves behind exactly one zombie process. The host is domain-joined and
  uses the IPA provider. Domain and server names are redacted below.
- 
  
  OBSERVED BEHAVIOUR
  
  The zombie and its parent:
  
-     $ ps -eo pid,ppid,stat,etime,comm,args | awk 'NR==1 || $3 ~ /^Z/'
-         PID    PPID STAT     ELAPSED COMMAND         COMMAND
-        1481    1439 Z       13:10:06 ldap_child      [ldap_child] <defunct>
+     $ ps -eo pid,ppid,stat,etime,comm,args | awk 'NR==1 || $3 ~ /^Z/'
+         PID    PPID STAT     ELAPSED COMMAND         COMMAND
+        1481    1439 Z       13:10:06 ldap_child      [ldap_child] <defunct>
  
-     $ ps -o pid,ppid,stat,lstart,comm,args -p 1439
-         PID    PPID STAT                  STARTED COMMAND         COMMAND
-        1439    1376 S    Sat Aug 22 20:07:04 2026 sssd_be         
/usr/libexec/sssd/sssd_be --domain EXAMPLE.COM --logger=files
+     $ ps -o pid,ppid,stat,lstart,comm,args -p 1439
+         PID    PPID STAT                  STARTED COMMAND         COMMAND
+        1439    1376 S    Sat Aug 22 20:07:04 2026 sssd_be         
/usr/libexec/sssd/sssd_be --domain EXAMPLE.COM --logger=files
  
  The elapsed time of the zombie matches the start time of its parent, so
  the child is forked and exits during backend startup and is then never
  reaped. It persists for the lifetime of the backend process.
  
  The domain is fully operational:
  
-     $ sssctl domain-status EXAMPLE.COM
-     Online status: Online
+     $ sssctl domain-status EXAMPLE.COM
+     Online status: Online
  
-     Active servers:
-     IPA: ipa-server.example.com
+     Active servers:
+     IPA: ipa-server.example.com
  
  /var/log/sssd/ldap_child.log exists but is empty (0 bytes) at the
  default debug level.
- 
  
  UPSTREAM FIX
  
  The upstream release notes list this change under SSSD 2.13.0, released
  on 2026-04-27:
  
-     pull request #8473, "sdap_select_principal_from_keytab_sync:
+     pull request #8473, "sdap_select_principal_from_keytab_sync:
  waitpid() synchronously"
  
-     https://github.com/SSSD/sssd/pull/8473
+     https://github.com/SSSD/sssd/pull/8473
  
  The title indicates a forked child that was not being waited on
  synchronously, which matches the symptom observed here: a single child,
  forked at backend startup, never reaped. I have not reviewed the diff
  itself.
  
  The change does not appear in the changelogs of the earlier maintenance
  releases listed on that page, so it is unlikely to reach Ubuntu 26.04
  through a point release and would need an individual cherry-pick.
  
  The current development release is affected as well. It ships upstream
  2.12.0, and its changelog up to 2.12.0-4ubuntu1 shows no distribution
  patch addressing this.
- 
  
  IMPACT
  
  One PID slot leaks for the lifetime of every sssd_be process.
  
  The count does not grow across restarts: when sssd_be exits, its zombie
  is reparented to the init system and reaped there, and the new backend
  creates exactly one replacement. Measured over five consecutive
  restarts, the count stayed at one. It also stayed at one over 13 hours
  of uninterrupted uptime.
  
  The practical cost is a single PID slot plus a defunct process that is
  permanently visible in the process table.
  
  Observed with the IPA provider. Judging by the function name the code
  path belongs to the LDAP provider layer, so AD and LDAP providers
  binding via GSSAPI from a keytab may be affected in the same way, but
  that has not been verified here.
  
- 
  STEPS TO REPRODUCE
  
  On a host joined to an IPA domain:
  
-     sudo systemctl restart sssd
-     sleep 20
-     ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/'
+     sudo systemctl restart sssd
+     sleep 20
+     ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/'
  
  Expected: no output.
  Actual:   one [ldap_child] entry in state Z, whose parent is sssd_be.
  
  Allow the full delay before sampling. The child is forked during backend
  startup, and a shorter wait can miss it.
  
- 
  PACKAGE INFORMATION
  
-     $ lsb_release -rd
-     Description:    Ubuntu 26.04 LTS
-     Release:        26.04
+     $ lsb_release -rd
+     Description:    Ubuntu 26.04 LTS
+     Release:        26.04
  
-     $ sssd --version
-     2.12.0
+     $ sssd --version
+     2.12.0
  
-     $ apt policy sssd
-     sssd:
-       Installed: 2.12.0-1ubuntu5.2
-       Candidate: 2.12.0-1ubuntu5.2
-       Version table:
-      *** 2.12.0-1ubuntu5.2 500
-             500 http://archive.ubuntu.com/ubuntu resolute-updates/main 
amd64v3 Packages
-             100 /var/lib/dpkg/status
-          2.12.0-1ubuntu5.1 500
-             500 http://archive.ubuntu.com/ubuntu resolute-security/main 
amd64v3 Packages
-          2.12.0-1ubuntu5 500
-             500 http://archive.ubuntu.com/ubuntu resolute/main amd64v3 
Packages
+     $ apt policy sssd
+     sssd:
+       Installed: 2.12.0-1ubuntu5.2
+       Candidate: 2.12.0-1ubuntu5.2
+       Version table:
+      *** 2.12.0-1ubuntu5.2 500
+             500 http://archive.ubuntu.com/ubuntu resolute-updates/main 
amd64v3 Packages
+             100 /var/lib/dpkg/status
+          2.12.0-1ubuntu5.1 500
+             500 http://archive.ubuntu.com/ubuntu resolute-security/main 
amd64v3 Packages
+          2.12.0-1ubuntu5 500
+             500 http://archive.ubuntu.com/ubuntu resolute/main amd64v3 
Packages

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2164856

Title:
  sssd_be leaves an [ldap_child] <defunct> zombie on every backend start

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2164856/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to