nslcd does not start on boot everytime

Bug #1029656 reported by Mike Holisky
76
This bug affects 16 people
Affects Status Importance Assigned to Milestone
nss-pam-ldapd (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I've been testing nslcd on ubuntu 12.04 and I feel that 0.8.10 needs to be released for 12.04. I also get lots of messages that seem to be fixed in releases after 0.8.4.

Even the developer says: 'Users that require a stable release are encouraged to stay with 0.7 until 0.8 stabilises.'
http://arthurdejong.org/nss-pam-ldapd/2011-09-04-release-0-8-4-of-nss-pam-ldapd

My main issue right now:
I've seen it not start on boot 50% of the time with different messages in syslog. If the daemon fails to start on boot and I start it from the init script, it works just fine with out any (related) errors or messages in syslog. Also if I put the daemon in debug mode on boot via the init script, I don't see this issue. But also at the same time the init script will still be executing because the daemon does not drop into the background.

This is an example if it failing to start on boot, here it fails to log any errors:
Jul 26 11:53:33 voodoo nslcd[1799]: version 0.8.4 starting
Jul 26 11:53:33 voodoo nslcd[1799]: accepting connections

This is an example if it failing to start on boot that points at Libgcrypt killing off the application:
Jul 26 14:45:10 voodoo nslcd[1245]: version 0.8.4 starting
Jul 26 14:45:10 voodoo nslcd[1245]: accepting connections
Jul 26 14:45:11 voodoo nslcd[1245]: Libgcrypt warning: missing initialization - please fix the application
Jul 26 14:45:11 voodoo nslcd[1245]: Libgcrypt notice: state transition Power-On => Fatal-Error
Jul 26 14:45:11 voodoo nslcd[1245]: Libgcrypt error: fatal error in file visibility.c, line 1283, function gcry_create_nonce: called in non-operational state
Jul 26 14:45:11 voodoo nslcd[1245]: Libgcrypt terminated the application

Oddly here is an example if the daemon starting on boot:
Jul 26 08:59:08 voodoo nslcd[1165]: version 0.8.4 starting
Jul 26 08:59:08 voodoo nslcd[1165]: accepting connections
Jul 26 08:59:10 voodoo nslcd[1165]: [3c9869] <passwd=""> "": name denied by validnames option

My nslcd.conf:
uid nslcd
gid nslcd

uri ldaps://10.x.x.110
uri ldaps://10.x.x.111

base dc=users,dc=accounts,dc=ldap,dc=mcad,dc=edu
base group dc=groups,dc=accounts,dc=ldap,dc=mcad,dc=edu

binddn cn=someuser,dc=bindAccts,dc=ldap,dc=mcad,dc=edu
bindpw somepass
filter passwd (&(objectClass=posixAccount)(uid=*)(employeeType=*))

ssl on
tls_reqcert never
map passwd homeDirectory "/home/$uid"
map passwd loginShell "/bin/bash"

Thanks for your work and any help.
-Mike

Revision history for this message
Arthur de Jong (adejong) wrote :

The libgcrypt problem is a known one without a known solution so far. Some background information is here:
http://bugs.debian.org/643948
https://bugzilla.redhat.com/506796

It seems to be a bug in either libgcrypt or OpenLDAP (I don't have time to dig into this at the moment though).

Revision history for this message
Mike Holisky (mholisky) wrote :

I'm sorry Arthur, I somehow missed that other bug report. I'm going to try and use the backport of 0.7.2 and see where that gets me. Thanks for your time and really quick response!
-Mike

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nss-pam-ldapd (Ubuntu):
status: New → Confirmed
Revision history for this message
Khaled Blah (khaled-blah) wrote :

I am posting this to confirm that this bug still exists in 14.04:

Apr 28 10:12:41 hostname nslcd[1020]: version 0.8.13 starting
Apr 28 10:12:46 hostname nslcd[1020]: accepting connections
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt warning: missing initialization - please fix the application
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt warning: missing initialization - please fix the application
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt notice: state transition Power-On => Fatal-Error
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt error: fatal error in file visibility.c, line 1283, function gcry_create_nonce: called in non-operational state
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt terminated the application
Apr 28 10:12:46 hostname nslcd[1020]: Libgcrypt error: invalid state transition Fatal-Error => Fatal-Error

Revision history for this message
Khaled Blah (khaled-blah) wrote :

Also, after reboot my machine (a KVM guest) several times I have to say it seems to be happening every time. I can start nslcd manually though.

Revision history for this message
linuxrrze (marcel-ritter) wrote :

Same here on all our Ubuntu 14.04 machines:

On boot nslcd stops working with this message:

nslcd[1431]: version 0.8.13 starting
nslcd[1431]: accepting connections
nslcd[1431]: Libgcrypt warning: missing initialization - please fix the application
nslcd[1431]: Libgcrypt notice: state transition Power-On => Fatal-Error
nslcd[1431]: Libgcrypt error: fatal error in file visibility.c, line 1283, function gcry_create_nonce: called in non-operational state
nslcd[1431]: Libgcrypt terminated the application

Moving /etc/rc2.d/S20nslcd to something like /etc/rc2.d/S99nslcd increased the chance to start nslcd automatically (however, we're starting apache and some other things in between, so in other configurations this may not work).

As all our new machines will be installed with Ubuntu 14.04 and authenticate against ldap servers (using TLS/SSL) this is a major problem for us.
Hope we'll get a fix for this problem soon.

Let me know if we can help to track down the problem!

Revision history for this message
linuxrrze (marcel-ritter) wrote :

I also tried to change the package name concerned:

I think it should be
   "nslcd"
not
   "nss-pam-ldapd"

Maybe that's why it didn't get the necessary attention for 2 years?

Revision history for this message
Arthur de Jong (adejong) wrote :

If you can reliably reproduce this, please try to supply debugging information as described in
  https://bugs.debian.org/643948#61
(specifically the gdb invocation of ldapsearch).

It this can be shown to be a problem in libldap or something else it can be chased in the appropriate package.

Any help tracking this down is very welcome.

Revision history for this message
linuxrrze-ag (andrei-g) wrote :

We could reproduce this issues and after 13 reboot attempts on a VM the nslcd wasn't running but the LDAP-Search succeded.
The relevant parts of the syslog and nslcd.ldapsearch.boot.log are attached.
If you need more information on this let us know.

Revision history for this message
Michael Korn (w-michael) wrote :

I can confirm that this problem exists since Ubuntu 12.04.
With Ubuntu 14.04 I observe this issue much more often. In fact during 3 of 4 reboots nslcd does not start correctly.

Revision history for this message
Michael Korn (w-michael) wrote :

I wanted to provide further information with ldapsearch (see https://bugs.debian.org/643948#61), but I realised that ldapsearch isn't wotking with ldaps (ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)).
Only ldap (without ssl) works.
The Server is configured to allow both and both ports response (389 and 636). Our Ubuntu Clients are configured to use use ssl (in ldap/ldap.conf and nslcd.conf).
Is there a connection to this issue?

Revision history for this message
Michael Korn (w-michael) wrote :

I found the solution:
About two years ago we got new workstations. The major part of the configuration was copied from the old workstations.
/etc/ldap/ldap.conf was copied, too.
The files specified by TLS_CERT and TLS_KEY were copied to the new workstations, but the file for TLS_CACERT was forgotten.

After copying the last file ldapsearch is working. And the login problems are gone!

There should be a warning about a missing file.

Revision history for this message
Michael Korn (w-michael) wrote :

I need to correct myself. This issue was gone for awhile. Then I had problems again on and off.
I can observe this issue regularly, now.

Maybe I will install a script as workaround, that calls "service nscd restart" one minute after booting. Any better suggestions?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.