web-dev-qa-db-fra.com

Pourquoi mon service systemd activé ne démarre-t-il pas au démarrage?

J'ai le fichier d'unité systemd suivant dans /etc/systemd/system/emacs.service:

[Unit]
Description=Emacs: the extensible, self-documenting text editor
Documentatin=man:emacs(1) info:Emacs


[Service]
Type=forking
ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(progn (setq kill-emacs-hook nil) (kill-emacs))"
Restart=always
Environment=DISPLAY=:%i
TimeoutStartSec=0

[Install]
WantedBy=default.target

Je veux que cela démarre au démarrage, j'ai donc entré systemctl enable emacs

Cependant, à chaque redémarrage de mon service, systemctl status emacs montre:

● emacs.service - Emacs: the extensible, self-documenting text editor
   Loaded: loaded (/etc/systemd/system/emacs.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Mais en entrant systemctl start emacs et en vérifiant les retours d'état:

● emacs.service - Emacs: the extensible, self-documenting text editor
   Loaded: loaded (/etc/systemd/system/emacs.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2016-11-11 23:03:59 UTC; 4s ago
  Process: 3151 ExecStart=/usr/bin/emacs --daemon (code=exited, status=0/SUCCESS)
 Main PID: 3154 (emacs)
    Tasks: 2
   Memory: 7.6M
      CPU: 53ms
   CGroup: /system.slice/emacs.service
           └─3154 /usr/bin/emacs --daemon

Comment puis-je obtenir ce processus pour démarrer avec succès au démarrage?

systemd
20
Startec

Je n'ai aucune idée pourquoi, mais pour que cela fonctionne, je:

supprimé Environment=DISPLAY=:%i

a ajouté un User= variable

Assurez-vous que le fichier correct était dans /etc/systemd/system/emacs.service (auparavant c'était un lien dur)

et relancé systemctl enable emacs

Cela l'a fait fonctionner.

EDIT Le vrai problème ici est que j'avais une faute de frappe à la ligne 3: Documentatin

J'ai trouvé cela en vérifiant journalctl. Je suggère à quiconque a des problèmes avec un script systemd de faire de même car aucune erreur n'a été envoyée à stderr.

10
Startec

ooh c'est intéressant.

Choisir une unité de service aléatoire et la regarder, cela dépend d'une cible spécifique au lieu de default.target. Ce dernier est symbolique ... un lien configuré vers une cible spécifique, sémantiquement cela n'a pas de sens. (Voir systemctl set-default)

Cela peut expliquer pourquoi votre service s'affiche sous la forme disabled après l'avoir activé. Essayez de remplacer default.target dans votre fichier de service avec multi-user.target, par exemple.

(Ne pas signaler une erreur lors de l'échec de l'activation semble être un défaut dans systemd. Je me demande presque si vous avez maintenant un répertoire /etc/systemd/system/default.target.wants).

3
sourcejedi

Vous avez une variable d'environnement DISPLAY, cela signifie que vous voulez que X11 soit démarré. Vous devez donc avoir un moyen de bloquer votre service jusque-là.

Cela se fait en utilisant le After=... option .

Je ne l'ai pas fait moi-même, donc je ne peux pas dire que cela fonctionnerait, mais c'est probablement quelque chose à voir avec graphical.target.

[Unit]
After=graphical.target

Une autre possibilité, si le serveur X ne démarre pas immédiatement (c'est-à-dire que vous avez un écran de connexion avec lightdm ou autre), alors vous devrez peut-être utiliser WantedBy=... à la place:

[Unit]
WantedBy=graphical.target

Si vous en avez assez de le faire fonctionner avec systemd, vous voudrez peut-être examiner la façon habituelle dont les gestionnaires X-Windows le font fonctionner.

Il y a le ~/.xprofile fichier, qui fonctionne comme le ~/.bashrc fichier.

Il y a aussi le ~/.config/autostart/*.desktop des dossiers. Il démarrera automatiquement toutes les applications qui y sont définies.

Ces solutions ne sont pas étendues au système, cependant, si vous avez plusieurs utilisateurs, chacun devrait avoir sa propre entrée. En outre, il ne démarre pas l'application en tant que root, mais vous à la place.

En remarque, le message "chargé + inactif (mort)" signifie que systemd a eu du mal à démarrer le processus et a donc décidé d'abandonner il. Vous pouvez tester manuellement que le name.service fonctionne une fois que vous avez redémarré en utilisant:

systemctl stop <service-name>
systemctl start <service-name>

Cela actualisera l'état et démarrera le service correctement, en supposant que les informations sont correctes. Vous pouvez ensuite vérifier à nouveau l'état pour voir des détails supplémentaires:

 systemctl status <service-name>
1
Alexis Wilke

C'est un bogue dans plusieurs fichiers de service de Debian:

# systemctl enable watchdog
Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable watchdog
# find /etc/systemd/ | grep watch
# tail -n2 /lib/systemd/system/watchdog.service

[Install]

https://www.raspberrypi.org/forums/viewtopic.php?f=82&t=218609&p=1406567#p1406567https://forum.armbian.com/topic/9115- ne-sais-toujours-pas-où-signaler-les bogues-watchdogservice-refuse-de-démarrer-en raison d'un fichier de service cassé /

Le correctif de niveau de distribution consiste à

echo "WantedBy=default.target" >> /lib/systemd/system/watchdog.service
systemctl daemon-reexec
systemctl enable watchdog
systemctl stop watchdog.service
systemctl start watchdog.service

Il existe de nombreuses alternatives manuelles à cela.

0
Benoit-Pierre DEMAINE