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
network-online.target 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:
nemo-desktop.servicewas 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.Notificationsis online. But there doesn’t seem to be a corresponding
dbus\x2d:1.2\x2dorg.freedesktop.Notifications.sliceI could hang
mpDris2off, to even duplicate my
alsa-volume-fix.serviceis a hack I’ve written to run an
alsamixercommand 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.)
alsa-volume-fix.serviceunit works if I run it manually (
systemctl --user restart alsa-volume-fix), but on startup it fails, presumably because it’s running before
pulseaudiohas finished transferring control of the desktop sound to my user login. This is despite the fact that I have it set to run
After=sound.target pulseaudio.service gnome-shell.service.
However, I just noticed there’s also a
pulseaudio.socketunit, 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.