Bug#792519: systemd-logind fails to start on system using LDAP

[Felipe Sateler]

On 15 July 2015 at 15:30, Daniel Schepler <dschepler at gmail.com> wrote:
> On Wed, Jul 15, 2015 at 11:15 AM, Felipe Sateler <fsateler at debian.org>
> wrote:
>>
>> On 15 July 2015 at 14:38, Daniel Schepler <dschepler at gmail.com> wrote:
>> > On Wed, Jul 15, 2015 at 10:18 AM, Felipe Sateler <fsateler at debian.org>
>> > 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.

Hmm. Could you please attach the upgrade logs since some time before
the problems occurred?  Might network manager have been updated in the
meantime?

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



-- 

Saludos,
Felipe Sateler