Bug 206307

Summary: net/openldap24-server: Sporadic crashes on CURRENT amd64
Product: Ports & Packages Reporter: O. Hartmann <ohartmann>
Component: Individual Port(s)Assignee: Xin LI <delphij>
Status: Closed Overcome By Events    
Severity: Affects Some People Keywords: crash, needs-qa
Priority: --- Flags: bugzilla: maintainer-feedback? (delphij)
koobs: merge-quarterly?
Version: Latest   
Hardware: Any   
OS: Any   

Description O. Hartmann 2016-01-16 10:28:38 UTC
Running CURRENT (recent version: FreeBSD 11.0-CURRENT #1 r294134: Sat Jan 16 08:48:04 CET 2016 amd64), I realise sporadic crashes of slapd, either after booting the system or out of the sudden. This issue occured wight after updating from version 2.4.42 to the recent version 2.4.43. Version 2.4.42 did not show this behaviour with the very same configuration.

All machines running CURRENT are involved, so it isn't an isolated, solitary problem of one specific configuration, I guess.

All systems in question run most recent ports

openldap-sasl-client-2.4.43
openldap-sasl-server-2.4.43
nss-pam-ldapd-sasl-0.8.14_3
cyrus-sasl-2.1.26_12

The servers are all configured to use MDB as the database backend.

I see in the log very often this line:

NSSWITCH(_nsdispatch): ldap, passwd, setpwent, not found, and no fallback provided

I have configured /etc/nsswitch.conf to first use cace, then files, then ldap with some [...] clauses to prevent nslcd/nsswitch being stuck when not able to access LDAP server or nslcd.

On one remote host, I have lost contact due to this nasty issue of crashing slapd and it isn't possible even for local users to login remotely anymore (get access to the remote lab in two weeks earliest to investigate). The crash occured couple of days before Christmas, so the issue also is related to older CURRENT. 

On hosts I have direct access, after the crash of the slapd server, login as root or any local configured user (fallback) takes incredible long time to log in, in most cases > 20s. I have configured /etc/nsswitch.conf with this line for each relevant entry (passwd/groups etc.):

[...]
passwd: cache [success=return notfound=continue unavail=continue tryagain=continue] files [success=return notfound=continue unavail=continue tryagain=continue] ldap [success=return notfound=return unavail=return tryagain=return]
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-16 15:26:35 UTC
If you can provide a backtrace (gdb -> bt) from the coredump as an attachment that would be great.

Bonus if you can reproduce the issue with a debug (WITH_DEBUG=yes) build, with backtrace

Thank you for the report!