2016-12-13 3 views
-1

Le problème n'est pas aussi facile qu'il n'y paraît dans le titre. J'utilise un paquet Tomcat 7 par défaut sur Unbutu 14.04 LTS. Quand je n'ai pas "setenv.sh" dans/usr/share/tomcat7/bin, il commence à dire "OK" quand je fais:setenv.sh provoquant l'échec de Tomcat7

$ sudo service tomcat7 start 

* Starting Tomcat servlet engine tomcat7 [OK] 

Lorsque j'utilise le setenv.sh décrit ci-dessous, il AUSSI COMMENCE sans erreur dans /var/lib/logs/catalina.out mais le service est détecté comme "ayant échoué" lorsque /etc/init.d/tomcat7 appelle "start-stop-daemon --test" et conclut qu'il n'est pas en cours d'exécution:

$ sudo service tomcat7 start 

* Starting Tomcat servlet engine tomcat7 [fail] 

Que puis-je faire à ce sujet?

/usr/share/tomcat7/bin/setenv.sh:

#! /bin/sh 
export JAVA_HOME="/home/linc/install/jdk1.7.0_75" 

(...)

# Check for application specific parameters at startup 
if [ -r "$CATALINA_BASE/bin/appenv.sh" ]; then 
. "$CATALINA_BASE/bin/appenv.sh" 
fi  

Il y a un autre problème, lié peut-être: quand je vérifie le processus courant après le démarrage détecté comme "échoué" (ps -ef | grep java), je peux voir toutes les options -D ajoutées par setenv.sh, mais je ne peux pas voir l'option -D ajoutée par "appenv.sh" (bien que setenv.sh et appenv .sh ont exactement les mêmes droits 755).

Remarque: si je lance sudo /usr/share/tomcat7/bin/startup.sh, setenv.sh ne pose aucun problème et appenv.sh est utilisé.

EDIT: J'ai peut-être trouvé la cause mais pas l'explication: quand j'enlève la déclaration de JAVA_HOME, il utilise le jvm par défaut et le démarrage du service est détecté comme "OK", mais quand je spécifie la valeur par défaut jvm, ça échoue à nouveau!

export JAVA_HOME="/usr/lib/jvm/java-8-oracle/jre" 

ou:

export JAVA_HOME="/usr/lib/jvm/java-8-oracle" 

Qu'est-ce qui se passe ici?

Répondre

0

Voici les explications.

Les tests de commande wether le service est ou non excpects non seulement un PID, mais aussi un binaire java précis:

start-stop-daemon --test --start --pidfile "$CATALINA_PID" \ 
          --user $TOMCAT7_USER --exec "$JAVA_HOME/bin/java" \ 
          >/dev/null; 

Ceci est exécuté 2 fois, l'une avant « catalina.sh » (et setenv. sh) est exécuté, un après. La configuration «standard» de tomcat sur ubuntu fonctionne comme ceci: /etc/init.d/tomcat7 peut être remplacé par/etc/default/tomcat7 qui peut être surchargé par catalina.sh (+ setenv.sh + appenv. sh).

Donc, il y a deux versions de JAVA_HOME, une première avec celle de/etc/default/tomcat7 ou une autre auto-détectée, et une seconde avec celle de setenv.sh. Cela fait échouer le test start-stop-daemon. La solution consisterait à définir deux fois JAVA_HOME, un dans/etc/default/tomcat7 pour le lancement du service, et un dans setenv.sh dans le cas où un lancement direct (via startup.sh in shell) doit être fait pour but du test, avec quelques commentaires d'avertissement sur la duplication.A propos de appenv.sh, la raison est CATALINA_BASE == CATLINA_HOME uniquement lorsque vous démarrez Tomcat à partir de la ligne de commande (startup.sh). Lors de l'exécution de Tomcat en tant que service CATALINA_BASE =/var/lib/tomcat7 alors que $ CATALINA_HOME =/usr/share/tomcat7. Par conséquent, mettre setenv.sh (et appenv.sh) dans/var/lib/tomcat7/bin/au lieu de/usr/share/tomcat7/bin résoud le problème.