[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
user
> > database, it means that logind depends on network to be up and
running.
> >
> > 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?
Dan
More information about the systemd-devel
mailing list