[systemd-devel] Create a new logind session from a systemd --user unit

Colin Walters walters at verbum.org
Mon Aug 5 12:55:35 PDT 2013


On Sun, 2013-08-04 at 10:46 -0400, Colin Walters wrote:

> https://people.gnome.org/~walters/user-session-patches

Now updated with various bugfixes.  PolicyKit works, the lock screen
works, etc.

However...let me call out one particular change:

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 7b9bd20..2fab003 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -485,6 +485,10 @@ static int bus_manager_create_session(Manager *m, DBusMessage *message) {
         }
 
         r = manager_get_session_by_pid(m, leader, &session);
+        if (!session) {
+                /* Fall back to the primary session */
+                r = manager_get_primary_session_by_pid(m, leader, &session);
+        }
         if (session) {
                 _cleanup_dbus_message_unref_ DBusMessage *reply = NULL;
                 _cleanup_free_ char *path = NULL;

I had to patch logind itself to have pkexec work (and similar would
apply to su/sudo).  At this point I think I've patched pretty much all
the interesting session lookup calls to fall back to primary.  Perhaps
that's not wrong, but it does give one pause.  I could just change
sd_pid_get_session() to do that by default...

Or maybe we should spawn user at .service from inside the first session,
and treat that as primary; add a new state like "user-linger" that
occurs if the user logs in twice, then closes the first one.

It would feel a lot less architecturally weird too if we changed getty
and ssh logins to behave the same way as gdm - i.e. we have
loginshell at .service, and keep around a dummy process.

So...dunno, it does feel hacky in some ways.

On the other hand, I'm *really* looking forward to being able to just
ssh/VT login into a machine and be able to run e.g. "gdbus monitor" and
"gsettings".




More information about the systemd-devel mailing list