[systemd-devel] Cycle between logind and NetworkManager in case of remote user database
Lennart Poettering
lennart at poettering.net
Tue Feb 3 10:33:42 PST 2015
On Tue, 16.12.14 08:45, David Herrmann (dh.herrmann at gmail.com) wrote:
> Hi
>
> On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams <dcbw at 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
More information about the systemd-devel
mailing list