Perché il mio servizio systemd abilitato non si avvia all'avvio?

20

Ho il seguente file di unità systemd in /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

Voglio che questo inizi all'avvio, quindi sono entrato systemctl enable emacs

Tuttavia, ogni volta che il mio servizio si riavvia, systemctl status emacsmostra:

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

Ma poi inserendo systemctl start emacse controllando lo stato ritorna:

● 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

Come posso avviare correttamente questo processo all'avvio?

systemd

— Startec
fonte

9

Non ho idea del perché, ma per farlo funzionare io:

soppresso Environment=DISPLAY=:%i

ha aggiunto una User=variabile

Assicurati che fosse presente il file corretto /etc/systemd/system/emacs.service(in precedenza era stato un collegamento reale)

e ripetuto systemctl enable emacs

Questo l'ha fatto funzionare.

EDIT Il vero problema qui è che ho avuto un refuso alla riga 3: Documentatin

Ho trovato questo controllando journalctl. Suggerisco a chiunque abbia problemi con uno script di systemd di fare lo stesso in quanto non è stato inviato alcun errore a stderr.

— Startec
fonte

Funziona anche al riavvio? Immagino che se la modalità demone non richiede una connessione X11, non è necessario per il After=...menzionato.

— Alexis Wilke,

1

Sì, funziona dopo il riavvio. Questo non è un Emac grafico, quindi non è necessario X11. Era solo una frase che ho copiato da un esempio e non ho prestato attenzione.

— Startec,

3

ooh questo è interessante.

Scegliere un'unità di servizio casuale e fissarla dipende da un obiettivo specifico anziché default.target. Quest'ultimo è simbolico ... un collegamento configurato a un obiettivo specifico, semanticamente non ha senso. (Vedi systemctl set-default)

Ciò potrebbe spiegare perché il servizio viene visualizzato come disableddopo averlo abilitato. Prova a sostituire default.targetnel tuo file di servizio multi-user.target, ad esempio.

(La mancata segnalazione di un errore in caso di mancata abilitazione sembra un difetto in systemd. Mi chiedo quasi se ora si dispone di una directory /etc/systemd/system/default.target.wants).

— sourcejedi
fonte

Il comando journalctl ti dice cosa si è rotto (perché l'attivazione non è riuscita, ad esempio.) Per quanto riguarda il collegamento, non è necessario se crei il tuo servizio personale. Non importa se crei un pacchetto che desideri che altri installino / rimuovano, ecc.

— Alexis Wilke,

@AlexisWilke Sarebbe ancora peggio! Perché dovrebbe essere scritto per segnalare alcuni errori a stderr e altri al diario?

— Fontejedi

Scrive tutto sul diario. Da quello che ho visto, vedi un errore molto semplice, specifico per il sistema, se non è stato possibile avviare il demone.

— Alexis Wilke,

2

l'utente non ha segnalato nemmeno un errore di base, ha ritenuto che l'operazione fosse riuscita e quindi ha proceduto al riavvio. al valore nominale, c'è un difetto in systemd. Gli utenti hanno anche modalità di errore, ma non mi sembrava che trascurare completamente un messaggio di errore fosse molto probabile in questa domanda.

— sourcejedi,

1

@sourcejedi Non ho idea di come lo sapessi, ma sì, ora ho un elenco su /etc/systemd/system/default.target.wants Inside che è il mio file di servizio. E sì, non avevo idea che ci fosse un errore.

— Startec,

1

Hai una variabile d'ambiente DISPLAY, ciò significa che vuoi avviare X11. Quindi devi avere un modo per bloccare il tuo servizio fino ad allora.

Questo viene fatto usando l' After=...opzione .

Non l'ho fatto da solo, quindi non posso dire che funzionerebbe, ma è probabilmente qualcosa a che fare con graphical.target.

[Unit]
After=graphical.target

Un'altra possibilità, se il server X non si avvia immediatamente (ovvero se hai una schermata di accesso con lightdm o simile), potresti dover usare WantedBy=...invece:

[Unit]
WantedBy=graphical.target

Se sei stanco di farlo funzionare con systemd, potresti voler esaminare il solito modo in cui i gestori X-Windows lo fanno funzionare.

C'è il ~/.xprofilefile, che funziona come il ~/.bashrcfile.

Ci sono anche i ~/.config/autostart/*.desktopfile. Avvierà automaticamente qualsiasi applicazione definita in esso.

Queste soluzioni non sono estese al sistema, tuttavia, nel caso in cui tu abbia più utenti, ognuno dovrebbe avere la propria voce. Inoltre, non avvia l'applicazione come root, ma tu, invece.

Come nota a margine, il messaggio "caricato + inattivo (morto)" indica che systemd ha avuto difficoltà a iniziare il processo e di conseguenza ha deciso di abbandonarlo . È possibile verificare manualmente che name.servicefunzioni dopo il riavvio utilizzando:

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

Ciò aggiornerà lo stato e avvierà il servizio correttamente, presupponendo che le informazioni siano corrette. È quindi possibile controllare nuovamente lo stato per visualizzare ulteriori dettagli:

 systemctl status <service-name>

— Alexis Wilke
fonte

2

Hm, ho cancellato l'intera riga e nulla è cambiato. Inoltre, (come ho detto nella mia domanda) inizia bene eseguendo systemctl start emacs).

— Startec,

vedi la mia domanda aggiornata. Ho avuto un errore di battitura Documentatin. Il tuo suggerimento su journalctlmi ha aiutato qui.

— Startec,

0

È un bug in diversi file di servizio di 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-to-report -bugs-watchdogservice-rifiuta-to-start-due-a-service file rotto /

La correzione del livello di distribuzione è

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

Ci sono molte alternative manuali a questo.

— Benoit-Pierre DEMAINE
fonte