[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