Systemd user unit ordering/scheduling

Over the past two Fedora releases, I’ve been slowly working on converting my $HOME/.config/autostart items into systemd user units. (#EmbraceChange and all.)

But I’m having difficulties with several user units failing, both my own and ones installed by packages, because they’re being executed before the desktop session (or, the parts of it they depend on) is fully started. So I’m wondering if anyone has any insights on service/target dependencies I can apply to delay the services longer, or has any clever ideas for improving startup ordering so that the necessary units will wait until they’re actually ready to be started.

Ideally what I’m looking for, I guess (unless someone convinces me it’s not what I really need; I’m more than willing to be talked out of my current thinking) is a target for my desktop session that represents something analogous to the system target: a sign that it’s ‘ready for use’, as opposed to merely “in the process of starting”. But there doesn’t seem to be any reasonable equivalent in the user session.

Barring that, well, here are some specifics:

  • My nemo-desktop.service was on this list, but it seems I finally fixed that one by setting it to start After=dbus\x2d:1.2\x2dorg.gnome.Nautilus.slice. That feels a bit hacky, but so far it’s succeeded following a single test reboot. (We’ll see if it’s reliable.) Still, if anyone has any other (preferably, better) suggestions, I’d be interested to hear.

  • mpDris2.service, the user unit for mpDris2 has a known problem that it starts up before the desktop notifications service is ready, causing it to log ERROR: No service handling org.freedesktop.Notifications; disabling notifications. The fixes being discussed are things like retrying the subscription, but that feels wrong to me. Better, I’d think, to just start it after org.freedesktop.Notifications is online. But there doesn’t seem to be a corresponding dbus\x2d:1.2\x2dorg.freedesktop.Notifications.slice I could hang mpDris2 off, to even duplicate my nemo-desktop hack.

  • My own alsa-volume-fix.service is a hack I’ve written to run an alsamixer command on startup that fixes a stupid problem. (My USB sound card initializes with the volume on the left channel — only the left channel — set to 0, which means I get no sound out of that one channel. But PulseAudio has no idea and thinks everything is fine, because the output isn’t muted from its perspective.)

    The alsa-volume-fix.service unit works if I run it manually (systemctl --user restart alsa-volume-fix), but on startup it fails, presumably because it’s running before pulseaudio has finished transferring control of the desktop sound to my user login. This is despite the fact that I have it set to run pulseaudio.service gnome-shell.service.

    However, I just noticed there’s also a pulseaudio.socket unit, so I’m going to set it to run after that, and maybe that’ll fix it.

I’m really stymied on the mpDris2.service thing, though.

1 Like

(Also $HOME/.config/autostart/ is just terrible. I don’t want to make it sound like I’m just being a joiner or want to use the newest, shiniest thing. I’m doing this because, whatever you think of SystemD generally, it’s certainly better for this purpose — or would be, if I knew how to use it right — than the crapfest that is the autostart directory. That trash can’t die fast enough.)

It’s not, as a second reboot has shown. (“Fortunately” they’re messing with the power in my building today, so I’m getting treated to more than the usual frequency of restarts.) So, nemo-desktop.service goes back on the list as another unit being started too early. (However, when that unit is launched too early it does actually exit with a non-zero result, so I’ve raised the RestartSec to 2s and I’m hoping that’ll help.)

alsa-volume-fix.service was also unsuccessful, even when started After=pulseaudio.socket. So, still 0 for 3 from the original list.