I servizi rimangono in stato di errore dopo l'interruzione con systemctl

19

abbiamo un semplice script di systemd per avviare un server MineCraft in modo di servizio. La SO è CentOS 7. Ecco lo 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

L'avvio del servizio funziona correttamente, ma quando si interrompe, il servizio rimane in uno stato non riuscito. Vedere:

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)

Qualche idea?

Grazie

systemd systemctl

— Kalise
fonte

27

Il codice di uscita 143 indica che il programma ha ricevuto un segnale SIGTERM per indicare di uscire, ma non ha gestito correttamente il segnale. Ciò è quasi sempre dovuto a errori di programmazione ed è abbastanza comune con le applicazioni Java di tutti i tipi.

Dovresti essere in grado di sopprimerlo aggiungendo il codice di uscita nel file di unità come stato di uscita "riuscito":

[Service]
SuccessExitStatus=143

— Michael Hampton
fonte

Funziona. Ora il servizio è nello stato inattivo, come previsto.

— Kalise,

4

Quale sarebbe il modo "corretto" di gestire il segnale con un'applicazione Java? Il più vicino che posso trovare sarebbe hook di arresto, ma in nessun punto della documentazione si menziona che gli hook di arresto alterano il codice di uscita dell'applicazione.

— Saluta il

@SPoage stackoverflow.com/q/2975248/1068283 Ma, sembra, Java esce sempre con il codice 143 in questo caso, anche se un gancio di arresto è presente.

— Michael Hampton

10

A complemento della risposta di Michael, il codice di uscita 143 è normale qui, è il modo in cui la VM Java ha ricevuto un segnale SIGTERM, inviato da systemd per interrompere il processo. Il segnale SIGTERM ha un valore numerico di 15 (vedi man signal).

Ora secondo la specifica Posix, "Lo stato di uscita di un comando che è terminato perché ha ricevuto un segnale deve essere riportato come maggiore di 128". ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_02 )

Qui la VM Java aggiunge 128 + 15 e ottieni questo codice di uscita di 143.

Questo codice di uscita diverso da zero qui ha senso, in quanto ciò consente di vedere che il tuo programma Java è uscito a causa di un segnale esterno e hai la possibilità di scoprire quale segnale.

— Manu
fonte

Il testo della specifica POSIX di riferimento sembra specificare il comportamento di una shell e dice "La shell è un interprete del linguaggio di comando". Una VM Java non sembra essere coperta da tale specifica. Il modo in cui una shell interpreta una VM Java (o qualsiasi altro programma) che termina a causa di SIGTERM - che dovrebbe impostare il codice di uscita su 143 - è certamente coperto dalle specifiche, ma sono abbastanza sicuro che qui non sia coinvolta una shell.

— Doshea,

Hai ragione nel dire che questa specifica POSIX è diretta sulla shell UNIX, ma qui sembra che gli autori di JVM abbiano deciso di implementare il loro codice di ritorno allo stesso modo.

— Manu,