On Wed, Jul 15, 2015 at 11:15 AM, Felipe Sateler <[email protected]> wrote:
> On 15 July 2015 at 14:38, Daniel Schepler <[email protected]> wrote: > > 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. > > Hmm, these messages look relevant as well: > > Jul 15 09:35:31 deb-dschepler dbus[836]: [system] Activating systemd > to hand-off: service name='org.freedesktop.login1' > unit='dbus-org.freedesktop.login1.service' > Jul 15 09:35:33 deb-dschepler dbus[836]: [system] Failed to activate > service 'org.freedesktop.nm_dispatcher': timed out > > Type=dbus units like bluetooth and avahi are also failing. Could you > test downgrading dbus? > > DBus being problematic could also account for your post-login woes. > Whoops, it looks like I actually had dbus 1.8.18-1 installed since before 2015-07-01 when my dpkg.log starts - which is well before the boot failures started. I must have been reading dpkg.log too quickly before and seeing trigger entries for dbus. Sorry about that. -- Daniel Schepler
