On Wed, Jul 15, 2015 at 10:18 AM, Felipe Sateler <[email protected]> wrote:
> This contains a massive amount of: > > Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: could not connect > to any LDAP server as (null) - Can't contact LDAP server > Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: failed to bind to > LDAP server ldap://dirsrv.snt.loc: Can't contact LDAP server > Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: reconnecting to > LDAP server (sleeping 1 seconds)... > > But with the service varying. > > I note that the NetworkManager service is started after many of those > messages. And after a while: > > Jul 15 09:35:09 deb-dschepler nscd[851]: nss_ldap: reconnected to LDAP > server ldap://dirsrv.snt.loc after 2 attempts > Jul 15 09:35:10 deb-dschepler ntpd[893]: Listen normally on 4 eth0 > 10.10.3.14 UDP 123 > Jul 15 09:35:10 deb-dschepler ntpd[893]: peers refreshed > > > So it looks like the problem is with your dns resolution? > Of course, networking has to be up before nslcd can connect to the LDAP server. But I didn't make any configuration changes related to this, and the setup was working just fine until last week. Checking /var/log/dpkg.log, about the only other package upgrade which seems like it could be remotely related is the upgrade of dbus to 1.8.18-1 at the same time. When I check network connectivity within the broken boot, it appears that eth0 is left up and configured even through the constant restarts of NetworkManager; and "getent passwd" includes entries from LDAP. -- Daniel Schepler
