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, donc je suis entré systemctl enable emacs

Cependant, chaque fois que mon service redémarre, systemctl status emacsaffiche:

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

Mais la saisie systemctl start emacset la vérification du statut renvoient:

● 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?

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

supprimé Environment=DISPLAY=:%i

ajouté une User=variable

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

et relance 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.

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 pourrait expliquer pourquoi votre service s'affiche comme disabledaprès l'avoir activé. Essayez de remplacer default.targetvotre fichier de service par 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).

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 l' 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 à la WantedBy=...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 ~/.xprofilefichier, qui fonctionne comme le ~/.bashrcfichier.

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

Ces solutions ne sont pas à l'échelle du 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é de l' abandonner . Vous pouvez tester manuellement le name.servicefonctionnement 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>

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#p1406567 https://forum.armbian.com/topic/9115-still-dont-know-where-where-to-report -bugs-watchdogservice-refuse-to-start-due-to-broken-service-file /

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.