skonfiguruj demona Java z systemd

Używam tej definicji do systemdpracy:

 [Unit]
 Description=Some job

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

 [Install]
 WantedBy=multi-user.target

Wywoływany jest następujący skrypt (wywoływanie prostej procedury, która nasłuchuje na gnieździe tcpip i dołącza dane wejściowe do pliku):

 #!/bin/sh

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

Gdy systemctl start somejobproces pokaże się jako uruchomiony, z initjego rodzicem:

 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

Po wykonaniu systemctl stop somejobproces nie jest już wyświetlany (a port jest zamknięty).

Wszystko wydaje się w porządku i eleganckie

Moje pytanie brzmi: czy jest to akceptowalne rozwiązanie do uruchamiania demona Java systemd, czy istnieją pewne zastrzeżenia, a zatem inne bardziej stabilne lub bezpieczne sposoby osiągnięcia tego celu?

Oto kilka drobnych modyfikacji:

1. Ponieważ nasłuchuje na gnieździe sieciowym, uczyń go zależnym od network.target.
2. nohupnie jest potrzebne, ponieważ systemddaemonize plik wykonywalny dla ciebie.
3. Myślę, że osobny skrypt powłoki byłby przesadą, więc po prostu połącz go z plikiem usługi.
4. Przekierowanie ( < /dev/nulli tak dalej) nie jest potrzebne, ponieważ systemd ustawia odpowiedni standardowy kontekst I / O. Rzeczywiście, jeśli wyjmiesz przekierowanie , systemd zapisze w dzienniku wszystko, co zostanie wysłane na standardowe wyjście przez program Java, bez specjalnego mechanizmu rejestrowania.
5. Asynchroniczne uruchamianie z powłoki wywołującej ( &) nie jest potrzebne ani właściwe.
6. Wymagany jest określony wzorzec zachowania Type=forking, a jeśli nie następuje po nim, wszystko idzie nie tak. Spróbuj więc Type=simple(lub Type=notify).

Plik usługi wygląda więc tak:

[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

Uwagi:

1. Nie można po prostu użyć javajako nazwy programu do uruchomienia. systemd nie szuka PATHplików wykonywalnych, a nazwa pliku wykonywalnego ExecStartmusi być bezwzględna. Jeśli więc chcesz przeszukiwać ścieżki, musisz wywołać je za pomocą powłoki lub /usr/bin/env. Wybieramy /bin/shtutaj.
2. Ponieważ jest Type=simpleto powłoka execJava, nie należy uruchamiać jej jako procesu potomnego. systemd kontroluje usługę przez główny proces, a to musi być Java, a nie proces powłoki nadrzędnej.
3. Ponieważ nie wywołuje to bezpośrednio pliku wykonywalnego Java, systemd umieści nazwę shw swoim dzienniku jako nazwę usługi. Zobacz Jak uniknąć oznaczania / usr / bin / env w logach systemd jako pliku wykonywalnego, aby dowiedzieć się więcej na ten temat.

O ile mi wiadomo, nie ma specjalnego ostrzeżenia dotyczącego uruchamiania aplikacji Java w Systemd.