[systemd-devel] Cycle between logind and NetworkManager in case of remote user database

Dan Williams dcbw at redhat.com
Mon Dec 15 09:34:17 PST 2014

On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
> On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> > NetworkManager sets logind inhibitor lock to monitor for suspend
> > events. So it implicitly requires logind to be present when NM
> > starts.

NM doesn't actually require that, it just wants to know about the
signals that logind sends and have a chance to respond to them.  If
logind isn't running, NM shouldn't really care.  But perhaps expectation
is not matching reality in the code.

> Any idea what it needs the inhibitor for?

To be aware of suspend/resume events of course.  NM may want to
disconnect the network cleanly before suspending, and on resume may need
to clean up network connections and restart certain operations.

> > logind is ordered after nss-user-lookup.target. If we have remote
> > database, it means that logind depends on network to be up and
> > 
> > If network is provided by NetworkManager we have a loop.
> > 
> > Due to the fact that NetworkManager service itself does not declare
> > dependency on logind, it can be pretty hard to recognize.
> > 
> > Any idea how it can be solved nicely? I can only think of delaying
> > inhibitor logic in NM until logind is started. Not sure what side
> > effects it may have.
> Yeah, I figure if they want to be able to run in early parts of boot
> they should watch logind's bus name and create their inhibitor only
> after it appears.

Does logind get D-Bus autolaunched?  NM is just creating a bus proxy for
the logind DBus service, and then attempting to call a D-Bus method on
logind to take an inhibitor.  It doesn't actually care that much about
the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
prohibit logind from launching.

Perhaps NM is requesting logind to start through D-Bus autolaunch, but
since the network isn't up yet logind then fails itself?


More information about the systemd-devel mailing list