<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 11, 2016 at 7:13 PM, Martin Pitt <span dir="ltr"><<a href="mailto:martin.pitt@ubuntu.com" target="_blank">martin.pitt@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I've been experimenting with systemd --user as a possible replacement<br>
for bringing up graphical user sessions. We currently bring up most of<br>
that using upstart jobs (simple auto-restart on crashes, rate<br>
limiting, per-job logging, fine-grained startup condition control).<br>
There is one upstart process per session, so this is reasonably<br>
straightforward.<br>
<br>
But I still can't wrap my head around the mental model of how this is<br>
supposed to work with the user D-Bus and systemd instance. This works<br>
fine for some services which are not specific to a session, such as<br>
gvfs or pulseaudio, but it's not at all appropriate for user-facing<br>
applications or desktop components, such as gnome-terminal[1],<br>
gnome-session, the window manager, indicators, etc. They are<br>
necessarily per-session, and sometimes even need to be keyed off the<br></blockquote><div><br></div><div>AFAIK, the general idea of --user is that there's at most one graphical session (per user) at a time, so things like $DISPLAY naturally become per user.</div><div><br></div><div>(It's not actually that bad, if you think how many people have been hardcoding :0 or grepping `ps -ef` to map an UID to display/xauthority/bus until now...)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",<br>
but this will hang off user@1000.service instead of session-*.scope<br>
and thus it will not be stopped once the X session gets logged out.<br></blockquote><div><br></div><div>Most X11 clients will exit as soon as the X server goes away, no?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Is this all in vain, and we need to make the *entire* world of free<br>
software shift over to the new model of "user-wide services" before we<br>
can use systemd --user for graphical stuff? (Colin's patch list is<br>
already impressively long and it is by far not complete)<br></blockquote><div><br></div><div>I think most programs will work as is just fine, as long as $DISPLAY is passed to the --user instance and the dbus-daemon.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Or is someone actually using systemd --user for graphical sessions<br>
already and found a trick that I missed?<br></blockquote><div><br></div><div>`systemctl --user import-environment DISPLAY` seems to work well enough. (There's also `dbus-update-activation-environment` which can push environment into both dbus-daemon and systemd at once.)</div><div><br></div><div>In stock GNOME, I already have a bunch of bus-activated apps running off the user bus (dbus.service), such as gedit, nautilus, or gnome-terminal; the latter finally got its own gnome-terminal.service in 3.20.2.</div><div><br></div><div>(I don't include XAUTHORITY in the above example because Xorg has long supported UID-based access control via `xhost +si:localuser:XXX`, e.g. gdm sets that up by default.)</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>