Package: sysklogd
Version: 1.5-6.1
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I upgraded debian testing today, and then the boot hung!
* What exactly did you do (or not do) that was effective (or
ineffective)?
Booted the machine.
* What was the outcome of this action?
Machine hung while running initscripts
* What outcome did you expect instead?
Normal boot.
*** End of the template - remove these lines ***
sysklogd starts before other services - so that they can use it for logging.
But this version of sysklogd seems to depend on username lookups
in such a way that it locks up waiting if ldap is configured. This
because ldap is not yet started when sysklogd starts.
I have some users in a ldap directory. Fortunately, it is a test
setup, therefore I could disable it without getting real problems.
Using "strace", I have seen that sysklogd tries to contact the
ldap server on its port. But "slapd" (the ldap server) is later
in the boot process. This used to work before, but now sysklogd
gets stuck waiting for an ldap server that will never show up.
After this, every service that log anything gets stuck, waiting
for sysklogd. This include the ldap service, which normally
logs a startup message during its initialization. It gets stuck
waiting for sysklogd, which again waits for ldap, so we
have a deadlock in userspace.
This is a regression, and makes ldap-enabled machines unuseable.
Machines without ldap is not affected.
WORKAROUND 1:
1. Boot in single-user mode
2. use "openvt" to get an extra shell
3. run "init 2"
4. when everything stops, restart sysklogd using the extra shell
5. watch everything come unstuck when sysklogd dies.
This includes the ldap server. When sysklogd restarts,
ldap is there and everything works. Except that every
service startup message was lost from the logs, of course.
WORKAROUND 2:
edit /etc/nsswitch.conf, disable ldap lookups there
After this, sysklogd doesn't try to use ldap too early, and works.
Clearly, this is not useful for those that use ldap in production.
IDEA FOR A FIX
ldap gets used by some people, sysklogd should still work.
Either revert to earlier
behavior, or take care to only look up stuff that a normal system
has in /etc/passwd or /etc/group. LDAP is not tried, when the
lookup succeed with the traditional files.
I hope this is fixable somehow. I can test experimental
versions, if that is useful.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages sysklogd depends on:
ii adduser 3.113
ii klogd [linux-kernel-log-daemon] 1.5-6.1
ii libc6 2.13-21
ii lsb-base 3.2-28
sysklogd recommends no packages.
sysklogd suggests no packages.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
