Re: [systemd-devel] Using systemd --user to manage graphical sessions?

[Mantas Mikulėnas]

On Thu, May 12, 2016 at 1:28 AM, Luke Shumaker 
wrote:
>
> The only problem I have with this setup is that dunst (my desktop
> notification daemon) isn't happy running multiple instances on
> different displays.  I think it's because it isn't happy sharing the
> dbus, but I haven't spent even 1 minute debugging it yet.
>

Yes, notification daemons always try to claim
"org.freedesktop.Notifications" with no session ID of any sort, so a second
instance would either fail or wait in the queue until the first one exits.

(Personally, my main session (GNOME/gdm) lives on the user bus, but
whenever I startx something temporary, it still calls dbus-launch to get a
temporary session bus.)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd --user to manage graphical sessions?

[Luke Shumaker]

On Wed, 11 May 2016 12:13:45 -0400,
Martin Pitt wrote:
> Or is someone actually using systemd --user for graphical sessions
> already and found a trick that I missed?

I am!  For several months now (and before that, I was still using
systemd --user for graphical stuff, but not consistently/coherently).

My configuration: https://lukeshu.com/git/dotfiles/tree/.config
Crappy write-up: https://lukeshu.com/blog/x11-systemd.html

One thing to note is that I don't use a DE, and have minimal
bus-activated services.

The big difference between what I do and what you wrote is that I
don't tie the DISPLAY name to the XDG_SESSION_ID (actually, the
session ID isn't even set in the graphical session).

The short version of how I have it work:

My ~/.xinitrc (AKA: script that starts the initial X11 clients)
contains:

_DISPLAY="$(systemd-escape -- "$DISPLAY")"
mkfifo "${XDG_RUNTIME_DIR}/x11-wm@${_DISPLAY}"
cat < "${XDG_RUNTIME_DIR}/x11-wm@${_DISPLAY}" &
systemctl --user start "X11@${_DISPLAY}.target" &
wait
systemctl --user stop "X11@${_DISPLAY}.target"

Which basically says: start X11@:0.target, wait for something to open
"${XDG_RUNTIME_DIR}/x11-wm@${_DISPLAY}" for writing and then close it,
then stop X11@:0.target.  Then I have my window manager configured to
open/close the file when I want to quit X11/log out (really, I have it
open at start, then just exit on quit; implicitly closing it).

Then, each of the whatever@${DISPLAY}.service files contains:

[Unit]
After=X11@%i.target
Requisite=X11@%i.target
[Service]
Environment=DISPLAY=%I

Now, when I launch a program from the window manager, I have it launch
with `systemd-run --user --scope -- sh -c "COMMAND HERE"`, so that
systemd can tell the difference between it and the window manager.  I
imagine that this would be problematic with less configurable window
managers.

As I type this, I have two graphical logins to the same user.  One on
a real screen, and the other with a fake screen via `vncserver` (of
course, managed as a systemd user unit :-) ).

The only problem I have with this setup is that dunst (my desktop
notification daemon) isn't happy running multiple instances on
different displays.  I think it's because it isn't happy sharing the
dbus, but I haven't spent even 1 minute debugging it yet.

-- 
Happy hacking,
~ Luke Shumaker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd --user to manage graphical sessions?

[Martin Pitt]

Hello Mantas,

thanks for your reply!

Mantas Mikulėnas [2016-05-11 19:54 +0300]:
> 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.

Right, I understand that. But that doesn't mean that *always* have a
$DISPLAY. So simply having user units that start with systemd --user
does not work: If the first login is on a VT or through ssh these
would all fail, and if you then actually login on the DM nothing would
restart them.

That could be helped a bit with a ConditionHasEnvironment=DISPLAY or
something such, and an xinit.d script that restarts them. But this can
all be achieved through some good/bad hacks, my main issue is still
that you can't bind those to the system unit with the correct
lifecycle -- session-*.scope.

> I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",
> > but this will hang off user@1000.service instead of session-*.scope
> > and thus it will not be stopped once the X session gets logged out.
> >
> 
> Most X11 clients will exit as soon as the X server goes away, no?

They do, but you get failed units and scary error messages, and this
happens *after* the X session is already gone -- thus no way for them
to gracefully shut down.

> `systemctl --user import-environment DISPLAY` seems to work well enough.

Right, that part works fine, that's not the problem.

> 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.

gnome-terminal is what I looked at too, and what I referred to in the
bug report: https://bugzilla.gnome.org/show_bug.cgi?id=744736 -- this
is pretty broken right now :-( This is essentially one program trying
to work around (and failing) the fundamental issue that a lot of
things don't make sense to start with the first non-X login and keep
around until after the X session ends.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd --user to manage graphical sessions?

[Mantas Mikulėnas]

On Wed, May 11, 2016 at 7:13 PM, Martin Pitt  wrote:

> Hello all,
>
> I've been experimenting with systemd --user as a possible replacement
> for bringing up graphical user sessions. We currently bring up most of
> that using upstart jobs (simple auto-restart on crashes, rate
> limiting, per-job logging, fine-grained startup condition control).
> There is one upstart process per session, so this is reasonably
> straightforward.
>
> But I still can't wrap my head around the mental model of how this is
> supposed to work with the user D-Bus and systemd instance. This works
> fine for some services which are not specific to a session, such as
> gvfs or pulseaudio, but it's not at all appropriate for user-facing
> applications or desktop components, such as gnome-terminal[1],
> gnome-session, the window manager, indicators, etc. They are
> necessarily per-session, and sometimes even need to be keyed off the
>

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.

(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...)

I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",
> but this will hang off user@1000.service instead of session-*.scope
> and thus it will not be stopped once the X session gets logged out.
>

Most X11 clients will exit as soon as the X server goes away, no?


> Is this all in vain, and we need to make the *entire* world of free
> software shift over to the new model of "user-wide services" before we
> can use systemd --user for graphical stuff? (Colin's patch list is
> already impressively long and it is by far not complete)
>

I think most programs will work as is just fine, as long as $DISPLAY is
passed to the --user instance and the dbus-daemon.


> Or is someone actually using systemd --user for graphical sessions
> already and found a trick that I missed?
>

`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.)

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.

(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.)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using systemd --user to manage graphical sessions?

[Martin Pitt]

Hello all,

I've been experimenting with systemd --user as a possible replacement
for bringing up graphical user sessions. We currently bring up most of
that using upstart jobs (simple auto-restart on crashes, rate
limiting, per-job logging, fine-grained startup condition control).
There is one upstart process per session, so this is reasonably
straightforward.

But I still can't wrap my head around the mental model of how this is
supposed to work with the user D-Bus and systemd instance. This works
fine for some services which are not specific to a session, such as
gvfs or pulseaudio, but it's not at all appropriate for user-facing
applications or desktop components, such as gnome-terminal[1],
gnome-session, the window manager, indicators, etc. They are
necessarily per-session, and sometimes even need to be keyed off the
session type (gnome, LXDE, XFCE, etc.). I. e. they should be started
on the first graphical session (not on VT logins) and should be
stopped when stopping the graphical session.

There are some existing discussions [2][3] and while the latter has a
lot of patches and some good direction, it does not really touch the
subject of the mail at all -- how do I get something from a user unit
into the session-*.scope session of logind?

I. e. if I have some ~/.config/systemd/user/xeyes@.service with

   [Unit]
   Description=Xeyes on session %I
   [Service]
   ExecStart=/usr/bin/xeyes

I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",
but this will hang off user@1000.service instead of session-*.scope
and thus it will not be stopped once the X session gets logged out.

One idea was to add PartOf=session-*.scope, but that's a system-level
unit and thus the session process does not know about that. There also
is no Scope= option for a service to make that run in a different
scope. We can certainly hook something into xinit.d/ to *start* a
"master stub" service which then launches the components, but there is
no way to tell it to stop with the logind session.

Is this all in vain, and we need to make the *entire* world of free
software shift over to the new model of "user-wide services" before we
can use systemd --user for graphical stuff? (Colin's patch list is
already impressively long and it is by far not complete)

Or is someone actually using systemd --user for graphical sessions
already and found a trick that I missed?

Thanks,

Martin


[1] https://bugzilla.gnome.org/show_bug.cgi?id=744736
[2] 
https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html
[3] https://lists.freedesktop.org/archives/systemd-devel/2013-August/012517.html

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel