¿Por qué mi servicio systemd habilitado no se inicia en el arranque?

20

Tengo el siguiente archivo de unidad systemd en /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

Quiero que esto comience en el arranque, así que he ingresado systemctl enable emacs

Sin embargo, cada vez que mi servicio se reinicia, systemctl status emacsmuestra:

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

Pero luego, al ingresar systemctl start emacsy verificar el estado, se devuelve:

● 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

¿Cómo puedo hacer que este proceso se inicie correctamente en el arranque?

systemd

— Startec
fuente

9

No tengo idea de por qué, pero para que esto funcione, yo:

eliminado Environment=DISPLAY=:%i

agregó una User=variable

Se aseguró de que el archivo correcto estaba en /etc/systemd/system/emacs.service(antes había sido un enlace duro)

y volvió a correr systemctl enable emacs

Esto lo hizo funcionar.

EDITAR El verdadero problema aquí es que tuve un error tipográfico en la línea 3: Documentatin

Encontré esto comprobando journalctl. Sugiero que cualquiera que tenga problemas con un script systemd haga lo mismo ya que no se envió ningún error a stderr.

— revs Startec
fuente

¿Eso también funciona en un reinicio? Supongo que si el modo demonio no requiere una conexión X11, entonces no hay necesidad de lo After=...que mencioné.

— Alexis Wilke

1

Sí, funciona después de reiniciar. Este no es un Emacs gráfico, por lo que no se necesita X11. Esa fue solo una línea que copié de un ejemplo y no presté atención.

— Startec

3

ooh esto es interesante

Elegir una unidad de servicio aleatoria y mirarla, depende de un objetivo específico en lugar de default.target. Este último es simbólico ... un enlace configurado a un objetivo específico, semánticamente no tiene sentido. (Ver systemctl set-default)

Eso podría explicar por qué su servicio se muestra disableddespués de habilitarlo. Intente reemplazar default.targeten su archivo de servicio con multi-user.target, por ejemplo.

(No informar un error cuando no se habilita parece un defecto en systemd. Casi me pregunto si ahora tiene un directorio /etc/systemd/system/default.target.wants).

— sourcejedi
fuente

El comando journalctl le dice qué falló (por qué falló la habilitación, por ejemplo). En cuanto al enlace, no es necesario si crea su propio servicio personal. Importa si crea un paquete que desea que otros instalen / eliminen, etc.

— Alexis Wilke

@AlexisWilke ¡Eso sería aún peor! ¿Por qué se escribiría para informar algunos errores a stderr y otros al diario?

— sourcejedi

Escribe todo al diario. Por lo que he visto, solo ves un error muy básico, específico del sistema, si no puede iniciar el demonio.

— Alexis Wilke

2

el usuario no informó ni siquiera un error básico, creía que la operación había tenido éxito y, por lo tanto, se reinició. a su valor nominal, hay un defecto en systemd. Los usuarios también tienen modos de falla, pero no me pareció que pasar por alto un mensaje de error fuera muy probable en esta pregunta.

— sourcejedi

1

@sourcejedi No tengo idea de cómo lo sabía, pero sí, ahora tengo una lista en /etc/systemd/system/default.target.wants Inside que son mis archivos de servicio. Y sí, no tenía idea de que había algún error.

— Startec

1

Tiene una variable de entorno DISPLAY, lo que significa que desea que se inicie X11. Por lo tanto, debe tener una forma de bloquear su servicio hasta entonces.

Esto se hace usando la After=...opción .

No lo he hecho yo mismo, así que no puedo decir que funcionaría, pero es probable que tenga algo que ver con eso graphical.target.

[Unit]
After=graphical.target

Otra posibilidad, si el servidor X no se inicia inmediatamente (es decir, tiene una pantalla de inicio de sesión con lightdm o similar), entonces puede que tenga que usar WantedBy=...en su lugar:

[Unit]
WantedBy=graphical.target

Si se cansa de que funcione con systemd, es posible que desee ver la forma habitual en que los administradores de X-Windows lo hacen funcionar.

Existe el ~/.xprofilearchivo, que funciona como el ~/.bashrcarchivo.

También están los ~/.config/autostart/*.desktoparchivos. Se iniciará automáticamente las aplicaciones definidas allí.

Sin embargo, estas soluciones no abarcan todo el sistema, en caso de que tenga varios usuarios, cada uno debería tener su propia entrada. Además, no inicia la aplicación como root, sino que usted, en cambio.

Como nota al margen, el mensaje "cargado + inactivo (muerto)" significa que systemd tuvo dificultades para iniciar el proceso y, como resultado, decidió abandonarlo . Puede probar manualmente que name.servicefunciona una vez que reinicia con:

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

Esto actualizará el estado e iniciará el servicio correctamente, suponiendo que la información sea correcta. Luego puede verificar el estado nuevamente para ver detalles adicionales:

 systemctl status <service-name>

— Alexis Wilke
fuente

2

Hm, borré toda esa línea y nada cambió. Además, (como dije en mi pregunta) comienza bien ejecutando systemctl start emacs).

— Startec

mira mi pregunta actualizada Tuve un error tipográfico Documentatin. Tu pista sobre journalctlme ayudó aquí.

— Startec

0

Es un error en varios archivos de servicio 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-to-report -bugs-watchdogservice-rechaza-a-empezar-debido-a-roto-service-file /

El nivel de distribución corregido es

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

Hay muchas alternativas manuales para esto.

— Benoit-Pierre DEMAINE
fuente