<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 at 12:30 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 15 July 2015 at 16:09, Daniel Schepler <<a href="mailto:dschepler@gmail.com">dschepler@gmail.com</a>> wrote:<br>
> On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler <<a href="mailto:fsateler@debian.org">fsateler@debian.org</a>><br>
<span class="">> wrote:<br>
>><br>
>> Hmm. Could you please attach the upgrade logs since some time before<br>
>> the problems occurred?  Might network manager have been updated in the<br>
>> meantime?<br>
><br>
><br>
> Attaching /var/log/dpkg.log.  I think the first failed boot was 2015-07-08<br>
> or 2015-07-09.  From the previous history, the last upgrade of dbus was:<br>
><br>
> 2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1<br>
><br>
>><br>
>> Also, how do you manage your connections?<br>
>><br>
>> I also found this old redhat bug[1]. Could you try adding a conf<br>
>> snippet to order the ldap components before dbus? Use systemctl edit<br>
>> <service> and add Before=dbus.service.<br>
>><br>
>><br>
>> [1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=502072" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=502072</a><br>
><br>
><br>
</span><span class="">> OK, it will be a while before I can test it because I'm doing work using the<br>
> machine right now.<br>
><br>
> It would appear to me from the logs that NetworkManager can't successfully<br>
> start before dbus is available - and I would probably want to make nslcd<br>
> dependent on networking being up.  Would that mean that I'd have to set<br>
> things up so it manually connects eth0 over DHCP, then starts nslcd, then<br>
> starts dbus?  And then NetworkManager would be left only managing wlan0?<br>
> And if so, where would I look for documentation on setting up the unit to<br>
> connect eth0?  (Sorry for the last very basic question.)<br>
<br>
</span>I think (but I'm not sure) that nm will still connect without dbus<br>
available yet, but it will of course not answer any dbus requests. So<br>
it should only be necessary to order ldap before dbus.<br>
<br>
However, this solution may prove brittle. Reading the linked redhat<br>
bug there are two promsing suggestions:<br>
<br>
1. Add 'bind_policy soft' to /etc/ldap.conf.<br>
2. Set nss_initgroups_ignoreusers to at least<br>
'root,dirsrv,gdm,rtkit,pulse,haldaemon,polkituser,avahi,dbus'<br>
<br>
It seems the problem is that nss_ldap is trying to query ldap for<br>
system users. That seems wrong to me, as the system should be able to<br>
work without network.<br></blockquote><div><br></div><div>I've added this to /etc/libnss-ldap.conf (just generated a list of system users where I had daemons running as them):</div><div><br></div><div>nss_initgroups_ignoreusers      root,avahi,clamav,colord,daemon,Debian-exim,Debian-gdm,dirmngr,gitdaemon,lp,messagebus,mysql,nslcd,ntp,rtkit,statd,www-data<br></div><div><br></div><div>But still, journalctl shows dbus-daemon, accounts-daemon and nscd (at least) giving the errors on being unable to connect to LDAP.  The machine did boot OK this morning, but as far as I know that could just be that I got lucky and hit the 10-20% success case.</div><div>-- </div><div>Daniel</div></div></div></div>