Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Tue, 16.12.14 08:45, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote: On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: 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 Thanks a lot! 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 doesn't crash and burn. If you talk to logind before its dependencies are fulfilled, and you do so synchronously, the method call will simply block until logind is up. There are two ways out here: a) not triggering activation by marking this in the bus message, or b) doing the method call asynchronously, rather than synchronously. Fix a) seems to be the right one here, since you'd really create a deadlock here otherwise. And I see that this is how you fixed it, so all is great. 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... When a user loggs in, we resolve the name to UID. As the initial logind binary was only used for login management, it was reasonable to avoid starting up before the nss-user-lookup is initialized. Now that systemd-logind provides other independent APIs, it might be ok to drop that requirement again. If the nss user lookup is not ready at the time someone logs in, we will print a warning and skip tracking that session. Sounds fine to me, but Lennart might have more comments. I am pretty sure we shouldn't allow user logins before the user database is fully accessible. If a user los in, he should see correct information about other users in ls -l output, and so on. It's OK to allow root to login earlier (and we do, via sulogin and stuff), but normal users during normal operation should not be allowed to do that. I am pretty sure we should leave the existing ordering as is. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
В Mon, 15 Dec 2014 14:20:45 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@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 Yes it was reported to fix the problems during system startup. Thank you! I wonder if there is any way to delay suspend in race free way. Also, I don't think logind should fail if there is no network; Logind was not even started - systemd waited for required services to start it and timed out. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Tue, 2014-12-16 at 08:45 +0100, David Herrmann wrote: Hi On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote: On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: 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 Thanks a lot! Update: the patch has been reviewed and pushed to NM git master (will eventually be 1.2), nm-1-0, and nm-0-9-10 branches. Dan 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... When a user loggs in, we resolve the name to UID. As the initial logind binary was only used for login management, it was reasonable to avoid starting up before the nss-user-lookup is initialized. Now that systemd-logind provides other independent APIs, it might be ok to drop that requirement again. If the nss user lookup is not ready at the time someone logs in, we will print a warning and skip tracking that session. Sounds fine to me, but Lennart might have more comments. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote: NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. Any idea what it needs the inhibitor for? 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
Hi On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams d...@redhat.com wrote: On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: 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 Thanks a lot! 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... When a user loggs in, we resolve the name to UID. As the initial logind binary was only used for login management, it was reasonable to avoid starting up before the nss-user-lookup is initialized. Now that systemd-logind provides other independent APIs, it might be ok to drop that requirement again. If the nss user lookup is not ready at the time someone logs in, we will print a warning and skip tracking that session. Sounds fine to me, but Lennart might have more comments. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cycle between logind and NetworkManager in case of remote user database
NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
