Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
- From: Dan Williams <dcbw redhat com>
- To: Andrei Borzenkov <arvidjaar gmail com>
- Cc: systemd Mailing List <systemd-devel lists freedesktop org>, networkmanager-list gnome org, Lennart Poettering <mztabzr 0pointer de>
- Subject: Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
- Date: Mon, 15 Dec 2014 14:20:45 -0600
On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
В Mon, 15 Dec 2014 11:34:17 -0600
Dan Williams <dcbw redhat com> пишет:
On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidjaar 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?
Yes.
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?
systemd tries to launch logind service which now waits for services it
is ordered After and eventually times out.
NM patch filed for review by NM dev team:
https://bugzilla.gnome.org/show_bug.cgi?id=741572
Also, I don't think logind should fail if there is no network; no reason
for it to crash and burn just because everything isn't quite ready when
it starts. I presume it's got capability to deal with sporadic network
outages, and that's not really different than waiting for networking to
show up soon after it starts. But not my department...
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]