Los servicios permanecen en estado fallido después de detenerse con systemctl

19

Tenemos un script systemd simple para iniciar un servidor MineCraft en forma de servicio. El SO es CentOS 7. Aquí el script:

[Unit]
Description=Minecraft Server
After=syslog.target network.target

[Service]
Type=simple
WorkingDirectory=/root/Minecraft
ExecStart=/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui
Restart=on-failure

[Install]
WantedBy=multi-user.target

Iniciar el servicio funciona bien, pero cuando se detiene, el servicio permanece en un estado fallido. Ver:

systemctl status minecraftd.service
minecraftd.service - Minecraft Server
   Loaded: loaded (/usr/lib/systemd/system/minecraftd.service; disabled)
   Active: active (running) since Mon 2015-06-01 16:00:12 UTC; 18s ago
 Main PID: 20975 (java)
   CGroup: /system.slice/minecraftd.service
           └─20975 /bin/java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui
systemctl stop minecraftd.service
systemctl status minecraftd.service
minecraftd.service - Minecraft Server
   Loaded: loaded (/usr/lib/systemd/system/minecraftd.service; disabled)
   Active: failed (Result: exit-code) since Mon 2015-06-01 16:01:37 UTC; 3s ago
  Process: 20975 ExecStart=/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui (code=exited, status=143)
 Main PID: 20975 (code=exited, status=143)

¿Alguna idea?

Gracias

systemd systemctl kalise
fuente

Respuestas:

27

El código de salida 143 significa que el programa recibió una señal SIGTERM para indicarle que salga, pero no manejó la señal correctamente. Esto casi siempre se debe a errores de programación, y es bastante común con aplicaciones Java de todo tipo.

Debería poder suprimir esto agregando el código de salida en el archivo de la unidad como un estado de salida "correcto":

[Service]
SuccessExitStatus=143
Michael Hampton
fuente
Funciona. Ahora el servicio está en estado inactivo, como se esperaba.
kalise
44
¿Cuál sería la forma "adecuada" de manejar la señal con una aplicación Java? Lo más cercano que puedo encontrar serían los ganchos de cierre, pero en ninguna parte de la documentación se menciona que los ganchos de cierre alteran el código de salida de la aplicación.
SPoage
@SPoage stackoverflow.com/q/2975248/1068283 Pero, al parecer, Java siempre sale con el código 143 en este caso, incluso si hay un gancho de cierre.
Michael Hampton
10

Para complementar la respuesta de Michael, el código de salida 143 es normal aquí, es la forma en que la VM Java recibió una señal SIGTERM, enviada por systemd para detener el proceso. La señal SIGTERM tiene un valor numérico de 15 (ver man signal).

Ahora, de acuerdo con la especificación Posix, "El estado de salida de un comando que finalizó porque recibió una señal se informará como mayor que 128". ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_02 )

Aquí la máquina virtual Java agrega 128 + 15 y obtienes este código de salida de 143.

Este código de salida distinto de cero aquí tiene sentido, ya que permite ver que su programa java salió debido a una señal externa, y tiene la oportunidad de averiguar qué señal.

Manu
fuente
El texto de especificación POSIX al que se hace referencia parece estar especificando cómo debe comportarse un shell y dice "El shell es un intérprete de lenguaje de comandos". Una máquina virtual Java no parece ser algo cubierto por esa especificación. La forma en que un shell interpreta una máquina virtual Java (o cualquier otro programa) que termina debido a SIGTERM, que debería establecer el código de salida en 143, ciertamente está cubierto por la especificación, pero estoy bastante seguro de que no hay un shell involucrado aquí.
doshea
Tienes razón en que esta especificación POSIX está dirigida al shell de UNIX, pero aquí parece que los autores de JVM decidieron implementar su código de retorno de la misma manera.
Manu