Konfigurieren Sie den Java-Daemon mit systemd

Ich verwende diese Definition für einen systemdJob:

 [Unit]
 Description=Some job

 [Service]
 ExecStart=/usr/local/sbin/somejob
 User=dlt
 Type=forking

 [Install]
 WantedBy=multi-user.target

Das Skript wird wie folgt aufgerufen (Aufruf einer einfachen Routine, die einen TCPIP-Socket abhört und die Eingabe an eine Datei anhängt):

 #!/bin/sh

 cd /home/user/tmp/testout
 nohup java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar </dev/null >/dev/null &

Nach dem systemctl start somejobProzess wird als ausgeführt angezeigt, mit initals übergeordnetem Element:

 user@CANTANDO ~$ ps -u dlt eo pid,ppid,command
   PID  PPID COMMAND
  8718     1 java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar

Nach dem Ausführen wird systemctl stop somejobder Vorgang nicht mehr angezeigt (und der Port ist geschlossen).

Also alles scheint gut und gut

Meine Frage ist: Ist dies eine akzeptable Lösung, um einen Java-Daemon mit systemdauszuführen, oder gibt es Vorbehalte und damit andere stabilere oder sicherere Wege, um dies zu erreichen?

Hier sind einige geringfügige Änderungen:

1. Machen Sie es zu einer Abhängigkeit von, da es einen Netzwerk-Socket abhört network.target.
2. nohupwird nicht benötigt, da systemddie ausführbare Datei für Sie daemonisiert wird.
3. Ich denke, ein separates Shell-Skript wäre ein Overkill, also füge es einfach in die Servicedatei ein.
4. Eine Umleitung ( < /dev/nullusw.) ist nicht erforderlich, da systemd einen geeigneten Standard-E / A-Kontext einrichtet. Ja, wenn Sie die Umleitung nehmen heraus systemd wird alles log auf die Standardausgabe durch das Java - Programm in seiner Zeitschrift geschickt, ohne spezielle Logging - Mechanismus erforderlich.
5. Das asynchrone Ausführen von der aufrufenden Shell ( &) ist nicht erforderlich oder angemessen.
6. Es gibt ein bestimmtes Verhaltensmuster, das von erforderlich ist Type=forking, und wenn es nicht von den Dæmon befolgt wird, gehen die Dinge schief. Also versuchen Sie es mit Type=simple(oder Type=notify).

Die Servicedatei sieht also folgendermaßen aus:

[Unit]
Description=Some job
After=network.target

[Service]
WorkingDirectory=/home/user/tmp/testout
SyslogIdentifier=SocketTest
ExecStart=/bin/sh -c "exec java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar"
User=dlt
Type=simple

[Install]
WantedBy=multi-user.target

Anmerkungen:

1. Sie können nicht einfach javaden Namen des auszuführenden Programms verwenden. systemd sucht nicht nach PATHausführbaren Dateien, und der Name der angegebenen ausführbaren Datei ExecStartmuss absolut sein. Wenn Sie also eine Pfadsuche wünschen, müssen Sie diese über eine Shell oder aufrufen /usr/bin/env. Wir wählen /bin/shhier.
2. Da dies Type=simpledie Shell ist, muss execJava nicht als untergeordneter Prozess ausgeführt werden. systemd steuert den Dienst über den Hauptprozess, und das muss Java sein, kein übergeordneter Shell-Prozess.
3. Da die ausführbare Java-Datei dadurch nicht direkt aufgerufen wird, fügt systemd den Namen shals Dienstnamen in sein Journal ein. Weitere Informationen hierzu finden Sie unter Vermeiden, dass / usr / bin / env in systemd-Protokollen als ausführbare Datei markiert wird .

Soweit ich weiß, gibt es keine besonderen Einschränkungen beim Ausführen von Java-Anwendungen mit Systemd.