Linux desktop application autostarting is different from systemd user units

July 12, 2020

When I wrote about how applications autostart on modern Linux desktops, there was a Reddit discussion, and one of the people there noted that things could also be autostarted through systemd user units. As covered in the Arch Wiki page on this, Linuxes that are systemd based generally automatically start a 'systemd --user' user systemd instance for you, and one of the things this will do is it will start things in ~/.local/share/systemd/user and ~/.config/systemd/user, which you can manipulate.

However, there are some significant differences between the two that help explain why Linux desktops don't use systemd user units. The big one is that systemd user units are per-user, not per-session. By their nature, desktop applications are a per session thing and so not a great fit for a per-user system. In fact even getting systemd user units to be able to talk to your desktop session takes what is basically a hack, as covered in the Arch wiki section on DISPLAY and XAUTHORITY, and this hack must be carefully timed so that it works correctly (it has to happen before units that need to talk to your desktop are started, and that means they have to be terminated when you log out).

Desktops also have a lot more fine control over what gets started with their current mechanisms. Obviously these things only get started for desktop sessions, not things like SSH logins, and they can be specific to certain desktops or not start in some desktops. I don't believe there is a native systemd unit option for 'run only if this environment variable is defined', so you can't readily make a systemd unit that only runs in desktop sessions, never mind only a particular sort of desktop.

(Relying to any significant degree on user units would also more strongly tie desktops to systemd, although I don't know if that's something they worry about these days or if it's full steam ahead on systemd in general.)

My general impression is that systemd user .service units are not a good fit for what most users want and do with autostarting things today, whether or not they're using a desktop. Systemd user units are probably a better fit for socket and dbus units, because those are more naturally activated on the fly as needed, but I don't know if people are doing this very much (especially for desktop related things).

(As a practical matter, I'd consider it pretty obnoxious if a program decided to set itself to autostart as a systemd user unit. I suspect I'm not alone in this.)


Comments on this page:

By Mike at 2020-07-12 02:30:07:

The upcoming systemd v246 will introduce an xdg-autostart-generator and xdg-desktop-autostart.target for this. Desktop files and ~/.config/autostart/ directories aren't going away, but expect to see them being managed through systemd in future desktop environment releases.

By Tom at 2020-07-12 06:27:36:

You can make systemd units conditional on an environment variable: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionEnvironment=

That said, just because you could use that doesn't mean you should - at least for this scenario.

By cks at 2020-07-12 12:05:16:

ConditionEnvironment seems to be very new in systemd; it's not in the systemd 243 that's in Fedora 31 or the systemd 245 that's in Ubuntu 20.04 (or at least it's not in their manual pages).

From 193.219.181.193 at 2020-07-17 06:00:15:

The big one is that systemd user units are per-user, not per-session. By their nature, desktop applications are a per session thing and so not a great fit for a per-user system.

Yes, but it's intentional - part of the developers' idea that there is only one graphical session per UID. (Possibly spanning multiple seats though.)

But I do miss the old days when systemd --user was still something I'd start from my xinitrc and not through some three levels of systemd-logind magic.

In fact even getting systemd user units to be able to talk to your desktop session takes what is basically a hack, as covered in the Arch wiki section on DISPLAY and XAUTHORITY, and this hack must be carefully timed so that it works correctly

It's an officially supported hack, one could say. IMHO it's not so much about careful timing as it is about understanding the general flow (that default.target is started through PAM before there's a display, and only gnome-session.target or whatever is started afterwards).

My general impression is that systemd user .service units are not a good fit for what most users want and do with autostarting things today, whether or not they're using a desktop. Systemd user units are probably a better fit for socket and dbus units, because those are more naturally activated on the fly as needed, but I don't know if people are doing this very much (especially for desktop related things).

They're okay for daemon type things, such as Transmission or Syncthing, though it's maybe a bit more useful if you've done loginctl enable-linger and everything starts right during boot.

Written on 12 July 2020.
« The impact on middleware of expanding APIs with Go's interface smuggling
Running servers and Fred Brooks on transforming programs to products »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 12 00:20:34 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.