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

Felipe Sateler fsateler at debian.org
Wed Jul 15 20:30:10 BST 2015


On 15 July 2015 at 16:09, Daniel Schepler <dschepler at gmail.com> wrote:
> On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler <fsateler at debian.org>
> 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.

-- 

Saludos,
Felipe Sateler




More information about the Pkg-systemd-maintainers mailing list