After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697594 - race with logind for finding our seat
race with logind for finding our seat
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
3.8.1
Depends on:
Blocks:
 
 
Reported: 2013-04-08 22:47 UTC by Colin Walters
Modified: 2013-04-09 19:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-slave-List-users-directly-via-DBus-don-t-use-libacco.patch (7.29 KB, patch)
2013-04-09 02:16 UTC, Colin Walters
none Details | Review

Description Colin Walters 2013-04-08 22:47:22 UTC
So I was debugging why https://bugzilla.gnome.org/show_bug.cgi?id=697292
 caused me to get into initial setup mode each time.

It appears to be because libaccountsservice can't find the current session (sometimes, it's racy), it says "giving up, setting the loaded property", which then in turn means we don't have any users yet, and then we get initial setup.

I think the race condition is with logind writing out the updated seat file when the session becomes active.  Verifying now.
Comment 1 Colin Walters 2013-04-08 23:13:40 UTC
Ok, I think this is quite simple - there is no session until the greeter starts, and to determine which greeter mode we should use, we need a session.

Looks like an accountsservice bug to me; why should we need to be in an active session to enumerate users?
Comment 2 Colin Walters 2013-04-08 23:14:24 UTC
I tried this patch, but it always fails because the daemon has no XDG_SESSION_ID.

diff --git a/src/libaccountsservice/act-user-manager.c b/src/libaccountsservice/act-user-manager.c
index 502df0e..d171fbc 100644
--- a/src/libaccountsservice/act-user-manager.c
+++ b/src/libaccountsservice/act-user-manager.c
@@ -1006,20 +1006,17 @@ on_get_current_session_finished (GObject        *object,
 static void
 _get_current_systemd_session_id (ActUserManager *manager)
 {
-        char *session_id;
-        int   res;
+        const char *session_id;
 
-        res = sd_seat_get_active ("seat0", &session_id, NULL);
+        session_id = g_getenv ("XDG_SESSION_ID");
 
-        if (res < 0) {
-                g_debug ("Failed to identify the current session: %s",
-                         strerror (-res));
+        if (session_id == NULL) {
+                g_debug ("Failed to identify the current session (no XDG_SESSION_ID)");
                 unload_seat (manager);
                 return;
         }
 
         manager->priv->seat.session_id = g_strdup (session_id);
-        free (session_id);
 
         manager->priv->seat.state++;
Comment 3 Matthias Clasen 2013-04-09 00:38:56 UTC
libaccountsservice clearly makes assumptions about being used inside a session.
But the slave runs outside the greeter session.
Can we just use accountsservice dbus api direction, and avoid the library in the slave ?
Comment 4 Colin Walters 2013-04-09 02:16:12 UTC
Created attachment 241005 [details] [review]
0001-slave-List-users-directly-via-DBus-don-t-use-libacco.patch
Comment 5 Colin Walters 2013-04-09 19:55:42 UTC
Went with a modified patch from Jasper.