Re: [systemd-devel] Using systemd --user to manage graphical sessions?
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?
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?
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?
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?
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