spring-boot launch-script: comment éviter le sous-répertoire identity-pid_folder?

Question

Nous utilisons spring-boot avec le script de lancement intégré dans le mode service, pour avoir un comportement de/dém.d daemonized.

Nous n'avons cependant pas de lien symbolique /etc/init.d vers le bocal à ressort car cela nécessiterait l'utilisation de sudo. nous évitons sudo passer un profil environnemental comme -Dspring.profiles.active=$APP_PROFILE dans le JAVA_OPTS (cela ne fonctionnera pas lors du démarrage par sudo mais défini dans /home/appuser/.bashrc (?))

Nous avons ce répertoire de mise en page avec quelques indirections. essentiellement app.jar => current/app.jar => build-xx/app.jar

appuser@host:~/apps/services$ ls 
app.jar -> /home/appuser/apps/services/current/services-1.0-SNAPSHOT.jar 
current -> /home/appuser/apps/services/services-1298 
services-1298 

Lors du démarrage de l'application avec app.jar start le script de lancement génère un pid-sous-répertoire supplémentaire dans le pid-dossier basé sur la « identité » du programme. Pour nous, cela peut ressembler à ceci:

/home/appuser/apps/services/run/services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298/services.pid 

Contrairement lorsqu'il est utilisé avec un lien symbolique /etc/init.d qui obtient un traitement spécial et le pid-subdir services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298 est omis/reste stable. Ce sous-répertoire dynamique pid nous rend très difficile de vérifier l'état du démon ou de démarrer/arrêter pendant le déploiement car vous devez toujours obtenir la séquence correcte et personne ne vous empêche de démarrer un processus deux fois (l'ancienne instance et maintenant une nouvelle instance avec un nouveau identity-subdir). Donc, est-ce que quelqu'un sait pourquoi cette substance pid-subdir-identity doit exister et quelle serait notre meilleure façon d'y faire face? Avons-nous une mauvaise configuration?

Un conseil apprécié.

Answer 1

Vous pouvez contrôler l'identité à l'aide de la variable d'environnement APP_NAME.

Je vous recommande de configurer les variables d'environnement de votre service à l'aide d'un fichier .conf à côté du fichier jar. Par exemple, si votre application est appelée app.jar, votre fichier conf doit être nommé app.conf et placé dans le même répertoire que le fichier jar. Vous pouvez ensuite configurer APP_NAME et JAVA_OPTS etc pour votre application. Cela devrait vous permettre d'utiliser init.d si vous le souhaitez.