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:
-
My
nemo-desktop.service
was on this list, but it seems I finally fixed that one by setting it to startAfter=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 logERROR: 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 afterorg.freedesktop.Notifications
is online. But there doesn’t seem to be a correspondingdbus\x2d:1.2\x2dorg.freedesktop.Notifications.slice
I could hangmpDris2
off, to even duplicate mynemo-desktop
hack. -
My own
alsa-volume-fix.service
is a hack I’ve written to run analsamixer
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 to0
, 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 beforepulseaudio
has finished transferring control of the desktop sound to my user login. This is despite the fact that I have it set to runAfter=sound.target 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.