configurer le démon java avec systemd


11

J'utilise cette définition pour un systemdtravail:

 [Unit]
 Description=Some job

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

 [Install]
 WantedBy=multi-user.target

Le script est appelé comme suit (appel d'une routine simple qui écoute sur un socket tcpip et ajoute l'entrée à un fichier):

 #!/bin/sh

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

Une fois le systemctl start somejobprocessus affiché comme en cours d'exécution, avec initcomme parent:

 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

Après avoir effectué systemctl stop somejoble processus ne s'affiche plus (et le port est fermé).

Donc tout semble bien et dandy

Ma question est: est-ce une solution acceptable pour exécuter un démon java avec systemd, ou y a-t-il des mises en garde, et donc d'autres moyens plus stables ou sécurisés pour y parvenir?

Réponses:


14

Voici quelques modifications mineures:

  1. Puisqu'il écoute sur une prise réseau, faites-en une dépendance de network.target.
  2. nohupn'est pas nécessaire car systemddémonifiera l'exécutable pour vous.
  3. Je pense qu'un script shell séparé serait une exagération, il suffit donc de le fusionner dans le fichier de service.
  4. La redirection ( < /dev/nullet ainsi de suite) n'est pas nécessaire car systemd configure un contexte d'E / S standard approprié. En effet, si vous supprimez la redirection , systemd enregistrera tout ce qui est envoyé à la sortie standard par le programme Java dans son journal, sans mécanisme de journalisation spécial requis.
  5. L'exécution asynchrone à partir du shell appelant ( &) n'est ni nécessaire ni appropriée.
  6. Il y a un modèle de comportement spécifique requis par Type=forking, et s'il n'est pas suivi par le démon, les choses tournent mal. Essayez donc pour Type=simple(ou Type=notify).

Ainsi, le fichier de service ressemble à ceci:

[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

Remarques:

  1. Vous ne pouvez pas simplement utiliser javacomme nom du programme à exécuter. systemd ne recherche pas PATHd'exécutables, et le nom de l'exécutable donné à ExecStartdoit être absolu. Donc, si vous voulez rechercher un chemin, vous devez l'invoquer via un shell ou /usr/bin/env. Nous choisissons /bin/shici.
  2. Parce que c'est Type=simplele shell doit execJava, pas l'exécuter en tant que processus enfant. systemd contrôle le service via le processus principal, et cela doit être Java, pas un processus shell parent.
  3. Comme cela n'invoque pas directement l'exécutable Java, systemd mettra le nom shdans son journal comme nom de service. Voir Comment éviter que / usr / bin / env soit marqué dans les journaux systemd comme exécutable pour plus d'informations.

Pour autant que je sache, il n'y a pas de mise en garde particulière concernant l'exécution d'une application Java avec Systemd.


1
Ça ne marchera pas. Problème 1: Ce n'est pas le shell; il n'y a pas d'opérateurs de redirection. Vous ne voulez pas vraiment cette redirection de toute façon. Problème 2: ExecStart exige des chemins d'accès absolus. Problème 3: unix.stackexchange.com/questions/229523
JdeBP

Belle tête haute. Je ne peux que résoudre le problème 1. Comment allez-vous résoudre le problème 2,3?
Yun-Chih Chen

1
Voir la réponse telle que modifiée.
JdeBP

Je ne pense pas que le sh soit nécessaire ici.
faho

Bonjour @ Yun-ChihChen comment arrêtez-vous le processus. À quoi ressemblerait ExecStrop? J'ai utilisé init.d avec un fichier pid mais j'ai trouvé cela plus facile. Je devais donc m'assurer de savoir comment m'arrêter, etc. Merci
black sensei
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.