update-manager doesn't prevent restart of slapd on system using ldap auth, resulting in hung update
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libpam-ldap (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
| openldap (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
| update-manager (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
Binary package hint: update-manager
The following version info is from AFTER the upgrade:
root@access:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid
At several points during an upgrade from Ubuntu karmic to lucid, many services are restarted. Unfortunately, update-manager appears to make no effort to protect services currently required for core system functionality from being stopped, and it can hang at these points until those services are manually restarted by the admin.
In my case, the problem service is slapd, because the system being upgraded is the LDAP master and it uses libpam-ldap and libnss-ldap (via the ldap-auth-client package) to do local authentication. If slapd is stopped, things tend to go very pear-shaped very fast with long timeouts and/or failures on system calls involving the nss subsystem.
The same issue probably arises with other authentication mechanisms that rely on daemons that may be running locally.
I noticed the upgrade "hang" after udev was updated and after libstdc++ was upgraded. In both cases ssh became non-responsive as did most other things. I had a local root console already open for just this situation, so I was able to restart slapd and get on with the install, but if I hand't been things could've been rather problematic
I'm sure there are other packages that may restart things at inopportune times, or stop them and expect something else to start them well down the track rather than restarting them on the spot.
One possible solution to this is to give the nss-ldap and nss-pam packages a way to protect slapd from being stopped during package installation, so it's only restarted momentarily at the end of the upgrade and when it its self is upgraded.
Alternately, disabling ldap etc auth via nssswitch.conf during the upgrade would work. update-manager would need to make sure that the core system users and groups were still in /etc/passwd and /etc/group though, as if the admin's moved them to the external auth source then disabling that auth source would not go well.
More package info:
root@access:~# apt-cache policy libpam-ldap libnss-ldap slapd ldap-auth-config ldap-auth-client update-manager update-manager-core
libpam-ldap:
Installed: 184-8ubuntu1
Candidate: 184-8.2ubuntu1
Version table:
184-8.2ubuntu1 0
500 http://
500 http://
*** 184-8ubuntu1 0
100 /var/lib/
libnss-ldap:
Installed: 261-2.1ubuntu4
Candidate: 264-2ubuntu2
Version table:
264-2ubuntu2 0
500 http://
500 http://
*** 261-2.1ubuntu4 0
100 /var/lib/
slapd:
Installed: 2.4.21-0ubuntu5
Candidate: 2.4.21-0ubuntu5
Version table:
*** 2.4.21-0ubuntu5 0
500 http://
500 http://
100 /var/lib/
ldap-auth-config:
Installed: 0.5.2
Candidate: 0.5.2
Version table:
*** 0.5.2 0
500 http://
500 http://
100 /var/lib/
ldap-auth-client:
Installed: 0.5.2
Candidate: 0.5.2
Version table:
*** 0.5.2 0
500 http://
500 http://
100 /var/lib/
update-manager:
Installed: (none)
Candidate: 1:0.134.7
Version table:
1:0.134.7 0
500 http://
500 http://
update-
Installed: 1:0.126.9
Candidate: 1:0.134.7
Version table:
1:0.134.7 0
500 http://
500 http://
*** 1:0.126.9 0
100 /var/lib/
| Changed in update-manager (Ubuntu): | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| Changed in libpam-ldap (Ubuntu): | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Changed in openldap (Ubuntu): | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Craig Ringer (ringerc) wrote | #1 |
| Craig Ringer (ringerc) wrote | #2 |
This issue is closely related to issue 356256.