O serviço systemd do usuário não reinicia após suspensão

O serviço systemd do usuário não reinicia após suspensão

Eu criei um serviço de usuário systemd para reiniciar o spotifyd após suspender, conforme sugerido na página do hub git do spotifyd. O problema que tenho é que ele nunca reinicia após a suspensão.

Este é o arquivo de serviço restartSpotifyd. Eu removi o

Reiniciar = sempre

do arquivo restartSpotifyd.service porque eu estava atingindo o limite inicial ('start-limit-hit'). Esta é a versão atualizada do arquivo de serviço:

.config/systemd/user/restartSpotifyd.service

[Unit]
Description=Restart spotifyd after resume
After=suspend.target

[Service]
Type=simple
ExecStart=/bin/systemctl --user --no-block restart spotifyd.service

[Install]
WantedBy=suspend.target

Quando suspendo e reinicio o computador e recebo isto:

systemctl --user status restartSpotifyd
● restartSpotifyd.service - Restart spotifyd after resume
     Loaded: loaded (/home/netlak/.config/systemd/user/restartSpotifyd.service; enabled; vendor preset: enabled)
     Active: inactive (dead)

May 26 15:04:13 jamming systemd[1361]: Stopped Restart spotifyd after resume.
May 26 15:04:13 jamming systemd[1361]: Started Restart spotifyd after resume.
May 26 15:04:13 jamming systemd[1361]: restartSpotifyd.service: Succeeded.
May 26 15:04:13 jamming systemd[1361]: restartSpotifyd.service: Scheduled restart job, restart counter is at 5.
May 26 15:04:13 jamming systemd[1361]: Stopped Restart spotifyd after resume.
May 26 15:04:13 jamming systemd[1361]: restartSpotifyd.service: Start request repeated too quickly.
May 26 15:04:13 jamming systemd[1361]: restartSpotifyd.service: Failed with result 'start-limit-hit'.
May 26 15:04:13 jamming systemd[1361]: Failed to start Restart spotifyd after resume.
May 26 15:06:21 jamming systemd[1361]: Started Restart spotifyd after resume.
May 26 15:06:21 jamming systemd[1361]: restartSpotifyd.service: Succeeded.

Às 15h10 suspendi o computador mas o serviço não foi reiniciado ao acordar. A última vez que foi reiniciado foi quando reiniciei manualmente o serviço às 15h06.

Isso está acontecendo no Debian e no Archlinux. Alguém pode me dar uma dica do que estou perdendo aqui?

informação relacionada