<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 at 11:15 AM, Felipe Sateler <span dir="ltr"><<a href="mailto:fsateler@debian.org" target="_blank">fsateler@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15 July 2015 at 14:38, Daniel Schepler <<a href="mailto:dschepler@gmail.com">dschepler@gmail.com</a>> wrote:<br>
> On Wed, Jul 15, 2015 at 10:18 AM, Felipe Sateler <<a href="mailto:fsateler@debian.org">fsateler@debian.org</a>><br>
> wrote:<br>
>><br>
>> This contains a massive amount of:<br>
>><br>
>> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: could not connect<br>
>> to any LDAP server as (null) - Can't contact LDAP server<br>
>> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: failed to bind to<br>
>> LDAP server ldap://dirsrv.snt.loc: Can't contact LDAP server<br>
>> Jul 15 09:34:37 deb-dschepler nslcd[905]: nss_ldap: reconnecting to<br>
>> LDAP server (sleeping 1 seconds)...<br>
>><br>
>> But with the service varying.<br>
>><br>
>> I note that the NetworkManager service is started after many of those<br>
>> messages. And after a while:<br>
>><br>
>> Jul 15 09:35:09 deb-dschepler nscd[851]: nss_ldap: reconnected to LDAP<br>
>> server ldap://dirsrv.snt.loc after 2 attempts<br>
>> Jul 15 09:35:10 deb-dschepler ntpd[893]: Listen normally on 4 eth0<br>
>> 10.10.3.14 UDP 123<br>
>> Jul 15 09:35:10 deb-dschepler ntpd[893]: peers refreshed<br>
>><br>
>><br>
>> So it looks like the problem is with your dns resolution?<br>
><br>
><br>
> Of course, networking has to be up before nslcd can connect to the LDAP<br>
> server.  But I didn't make any configuration changes related to this, and<br>
> the setup was working just fine until last week.  Checking<br>
> /var/log/dpkg.log, about the only other package upgrade which seems like it<br>
> could be remotely related is the upgrade of dbus to 1.8.18-1 at the same<br>
> time.<br>
><br>
> When I check network connectivity within the broken boot, it appears that<br>
> eth0 is left up and configured even through the constant restarts of<br>
> NetworkManager; and "getent passwd" includes entries from LDAP.<br>
<br>
</div></div>Hmm, these messages look relevant as well:<br>
<br>
Jul 15 09:35:31 deb-dschepler dbus[836]: [system] Activating systemd<br>
to hand-off: service name='org.freedesktop.login1'<br>
unit='dbus-org.freedesktop.login1.service'<br>
Jul 15 09:35:33 deb-dschepler dbus[836]: [system] Failed to activate<br>
service 'org.freedesktop.nm_dispatcher': timed out<br>
<br>
Type=dbus units like bluetooth and avahi are also failing. Could you<br>
test downgrading dbus?<br>
<br>
DBus being problematic could also account for your post-login woes.<br></blockquote><div><br></div><div>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.</div><div>-- </div><div>Daniel Schepler</div></div></div></div>