On 17 July 2015 at 18:44, Daniel Schepler <[email protected]> wrote: > On Wed, Jul 15, 2015 at 12:30 PM, Felipe Sateler <[email protected]> > wrote: >> >> On 15 July 2015 at 16:09, Daniel Schepler <[email protected]> wrote: >> > On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler <[email protected]> >> > wrote: >> >> >> >> Hmm. Could you please attach the upgrade logs since some time before >> >> the problems occurred? Might network manager have been updated in the >> >> meantime? >> > >> > >> > Attaching /var/log/dpkg.log. I think the first failed boot was >> > 2015-07-08 >> > or 2015-07-09. From the previous history, the last upgrade of dbus was: >> > >> > 2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1 >> > >> >> >> >> Also, how do you manage your connections? >> >> >> >> I also found this old redhat bug[1]. Could you try adding a conf >> >> snippet to order the ldap components before dbus? Use systemctl edit >> >> <service> and add Before=dbus.service. >> >> >> >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=502072 >> > >> > >> > OK, it will be a while before I can test it because I'm doing work using >> > the >> > machine right now. >> > >> > It would appear to me from the logs that NetworkManager can't >> > successfully >> > start before dbus is available - and I would probably want to make nslcd >> > dependent on networking being up. Would that mean that I'd have to set >> > things up so it manually connects eth0 over DHCP, then starts nslcd, >> > then >> > starts dbus? And then NetworkManager would be left only managing wlan0? >> > And if so, where would I look for documentation on setting up the unit >> > to >> > connect eth0? (Sorry for the last very basic question.) >> >> I think (but I'm not sure) that nm will still connect without dbus >> available yet, but it will of course not answer any dbus requests. So >> it should only be necessary to order ldap before dbus. >> >> However, this solution may prove brittle. Reading the linked redhat >> bug there are two promsing suggestions: >> >> 1. Add 'bind_policy soft' to /etc/ldap.conf. >> 2. Set nss_initgroups_ignoreusers to at least >> 'root,dirsrv,gdm,rtkit,pulse,haldaemon,polkituser,avahi,dbus' >> >> It seems the problem is that nss_ldap is trying to query ldap for >> system users. That seems wrong to me, as the system should be able to >> work without network. > > > I've added this to /etc/libnss-ldap.conf (just generated a list of system > users where I had daemons running as them): > > nss_initgroups_ignoreusers > root,avahi,clamav,colord,daemon,Debian-exim,Debian-gdm,dirmngr,gitdaemon,lp,messagebus,mysql,nslcd,ntp,rtkit,statd,www-data > > 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.
Please report back if this happens agains. As it is, there is not much we can do. I think what you really want is to tell ldap to never lookup groups < 1000, but I don't know if you can do that. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
