Your message dated Sat, 30 Sep 2006 01:26:21 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Fixed in NMU of libnss-ldap 251-5.2
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libnss-ldap
Version: 251-1
Severity: grave
To relevant parts of nsswitch.conf on my system look like this:
passwd: files ldap
group: files ldap
shadow: files ldap
libnss_ldap is configured to query a remote LDAP server.
This makes booting stuck if you use udevd (which most systems will
do nowadays) so I'm filing this bug grave.
These are the messages I get:
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd
udevd[374]: nss_ldap: could not connect to any LDAP server as (null) -
Can't contact LDAP server
udevd[374]: nss_ldap: failed to bind to LDAP server ldaps://foo.bar:
Can't contact LDAP server
udevd[374]: nss_ldap: could not connect to any LDAP server as (null) -
Can't contact LDAP server
udevd[374]: nss_ldap: failed to bind to LDAP server ldaps://foo.bar:
Can't contact LDAP server
udevd[374]: nss_ldap: could not connect to any LDAP server as (null) -
Can't contact LDAP server
udevd[374]: nss_ldap: failed to bind to LDAP server ldaps://foo.bar:
Can't contact LDAP server
udevd[374]: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)
...
And so on. The sleep interval is doubled each time(4,8,16,32,64
seconds...). The boot process get's stuck completely. If I press STRG+C,
udevd is killed and no devices are created, causing to fail the boot
process completely.
I had to boot from a rescue CD to fix this and remove the above lines
from nsswitch.conf again.
Michael
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.1
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages libnss-ldap depends on:
ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libkrb53 1.4.3-7 MIT Kerberos runtime libraries
ii libldap2 2.1.30-13+b1 OpenLDAP libraries
Versions of packages libnss-ldap recommends:
ii libpam-ldap 180-1 Pluggable Authentication Module al
ii nscd 2.3.6-15 GNU C Library: Name Service Cache
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Version: 251-5.2
I've NMUed for this bug (fixing the bug to use versioning instead of the
"fixed" tag, to ease tracking through testing); here's the changelog:
> libnss-ldap (251-5.2) unstable; urgency=high
> .
> * Non-maintainer upload.
> * When doing substitutions in libnss-ldap.conf, pass the values to the Perl
> program as environment variables instead of directly to the program;
> should eliminate the problems with having to escape them.
> (Closes: #376684, #386141)
> * Change the init script policy. Instead of stopping libnss-ldap.init on
> clean shutdown (touching a file) and starting it after networking (rm-ing
> it), we touch the file in /lib/init/rw as soon as possible (right before
> udev is started, touching a file) and stop it after initial system
> bootup.
> This fixes both issues with /var being on a separate partition, and
> unclean shutdown where the file would not be created. (To make sure we
> don't get similar problems during shutdown, we create it in runlevels 0
> and 6 as before, but we don't assume it's still there when we boot, since
> it's on a tmpfs now.) (Closes: #375077)
> * Block SIGPIPE in do_atfork_child(), as some versions of libldap2 in some
> circumstances (notably with TLS enabled) write data onto our dummy socket
> during close, which raises a SIGPIPE that should not be delivered on to
> the
> application. (Closes: #376426, #388574)
/* Steinar */
--
Homepage: http://www.sesse.net/
--- End Message ---
