Tomcat7 démarre trop tard sur Ubuntu 14.04 x64 [Digitalocean]
j'utilise digitalocean et j'essaie d'installer et de démarrer Tomcat sur ubuntu mais malheureusement je ne peux pas le faire. (créé de nouvelles gouttelettes et essayé 10 fois)
Disque SSD 1 Go Ram 30 Go Amsterdam 2 Ubuntu 14.04 x64
Quand je démarre Tomcat, il est écrit "Tomcat a commencé". Mais je ne peux pas accéder à la page depuis le navigateur. et ./shutdown.sh renvoie une erreur.
Quel peut être le problème ?
J'ai remarqué quelque chose maintenant. Pendant que j'écris cette question, la page Tomcat s'affiche. Il a fallu 28 minutes pour afficher la page
catalina.out dit: INFO: La création d'une instance SecureRandom pour la génération d'ID de session à l'aide de [SHA1PRNG] a pris [1 718 769] millisecondes.
Voici mes étapes d'installation (ces étapes fonctionnent sur différents vps mais ne fonctionnent pas sur les droplets digitalocean):
Installer Oracle jdk
Sudo apt-get install python-software-properties
Sudo add-apt-repository ppa:webupd8team/Java
Sudo apt-get update
Sudo apt-get install Oracle-Java7-installer
Sudo apt-get install Oracle-Java7-set-default
Java -version
Java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
Définir Java chemin
Sudo nano /etc/environment
Java_HOME="/usr/lib/jvm/Java-7-Oracle"
source /etc/environment
wget http://ftp.itu.edu.tr/Mirror/Apache/Tomcat/tomcat-7/v7.0.56/bin/Apache-Tomcat-7.0.56.tar.gz
tar xvzf Apache-Tomcat-7.0.56.tar.gz
mv Apache-Tomcat-7.0.56/ Apache-Tomcat-7.0.56-server-1/
Démarrer Tomcat
./startup.sh
Using CATALINA_BASE: /usr/local/Apache-Tomcat-7.0.56-server-1
Using CATALINA_HOME: /usr/local/Apache-Tomcat-7.0.56-server-1
Using CATALINA_TMPDIR: /usr/local/Apache-Tomcat-7.0.56-server-1/temp
Using JRE_HOME: /usr/lib/jvm/Java-7-Oracle/jre
Using CLASSPATH: /usr/local/Apache-Tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/Apache-Tomcat-7.0.56-server-1/bin/Tomcat-juli.jar
Tomcat started.
Port de sortie 8080
netstat -ln
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::8009 :::* LISTEN
tcp6 0 0 :::8080 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
Processus de paiement
ps -ef | grep Tomcat
root 2825 1 1 14:23 pts/0 00:00:03 /usr/lib/jvm/Java-7-Oracle/jre/bin/Java -Djava.util.logging.config.file=/usr/local/Apache-Tomcat-7.0.56-server-1/conf/logging.properties -Djava.util.logging.manager=org.Apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/Apache-Tomcat-7.0.56-server-1/endorsed -classpath /usr/local/Apache-Tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/Apache-Tomcat-7.0.56-server-1/bin/Tomcat-juli.jar -Dcatalina.base=/usr/local/Apache-Tomcat-7.0.56-server-1 -Dcatalina.home=/usr/local/Apache-Tomcat-7.0.56-server-1 -Djava.io.tmpdir=/usr/local/Apache-Tomcat-7.0.56-server-1/temp org.Apache.catalina.startup.Bootstrap start
Ouvrir le site Web au port 8080 http://5.101.107.56:8080/ La page est en attente ... [le contenu s'affiche après 28 minutes ou plus]
Essayez d'arrêter Tomcat si le contenu n'est pas encore affiché (avant que Tomcat démarre correctement).
./shutdown.sh
SEVERE: Could not contact localhost:8005. Tomcat may not be running.
Oct 17, 2014 2:40:29 PM org.Apache.catalina.startup.Catalina stopServer
SEVERE: Catalina.stop:
Java.net.ConnectException: Connection refused
at Java.net.PlainSocketImpl.socketConnect(Native Method)
at Java.net.AbstractPlainSoc
Journaux de paiement
catalina.out
Oct 17, 2014 2:31:47 PM org.Apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Oct 17, 2014 2:31:47 PM org.Apache.catalina.startup.Catalina load
INFO: Initialization processed in 1492 ms
Oct 17, 2014 2:31:47 PM org.Apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Oct 17, 2014 2:31:47 PM org.Apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.56
Oct 17, 2014 2:31:47 PM org.Apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /usr/local/Apache-Tomcat-7.0.56-server-1/webapps/Host-manager
J'ai également installé nginx et accédez à http://5.XXX.XXX.XX/ La page d'accueil de nginx s'ouvre immédiatement
J'ai vérifié catalina.out quand je vois la page dans le navigateur, cela dit:
Oct 17, 2014 2:31:47 PM org.Apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /usr/local/Apache-Tomcat-7.0.56-server-1/webapps/Host-manager
Oct 17, 2014 3:00:27 PM org.Apache.catalina.util.SessionIdGenerator createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took **[1,718,769] milliseconds.**
Mémoire:
total used free shared buffers cached
Mem: 1017912 849512 168400 332 18780 688468
Remplacement de securerandom.source=file:/dev/urandom avec securerandom.source=file:/dev/./urandom dans $Java_PATH/jre/lib/security/Java.security a résolu mon problème.
Même quand file:/dev/urandom est spécifié, JRE utilisera toujours /dev/random pour SHA1PRNG (voir bug JDK-470509 ):
Dans SHA1PRNG, il y a un SeedGenerator qui fait diverses choses selon la configuration.
Si Java.security.egd ou securerandom.source pointe vers "file:/dev/random" ou "file:/dev/urandom", nous utiliserons NativeSeedGenerator, qui appelle super () qui appelle SeedGenerator.URLSeedGenerator (/ dev/random ). (Une classe imbriquée dans SeedGenerator.) La seule chose qui a changé dans ce bogue est que urandom déclenchera également l'utilisation de ce chemin de code.
Si ces propriétés pointent vers une autre URL qui existe, nous initialiserons SeedGenerator.URLSeedGenerator (url). C'est pourquoi "file: /// dev/urandom", "file: /./ dev/random", etc. fonctionnera.
Dans cette implémentation, le générateur conserve une estimation du nombre de bits de bruit dans le pool d'entropie. À partir de ce pool d'entropie, des nombres aléatoires sont créés. Lors de la lecture, le périphérique/dev/random ne renverra que des octets aléatoires dans le nombre estimé de bits de bruit dans le pool d'entropie. /dev/random devrait convenir aux utilisations qui nécessitent un caractère aléatoire de très haute qualité , comme la génération d'un bloc ou d'une clé.
Lorsque le pool d'entropie est vide, lit à partir de/dev/random va bloquer jusqu'à ce que du bruit environnemental supplémentaire soit collecté. Le l'intention est de servir de générateur de nombres pseudo-aléatoires cryptographiquement sécurisé, fournissant une sortie avec entropie aussi grande que possible. Ceci est suggéré pour une utilisation dans la génération de clés cryptographiques pour une protection à haute valeur ou à long terme.
Bruit environnemental?
Le générateur de nombres aléatoires rassemble le bruit environnemental des pilotes de périphérique et d'autres sources dans une piscine entropique. Le générateur conserve également une estimation du nombre de bits de bruit dans le pool d'entropie. À partir de ce pool d'entropie, des nombres aléatoires sont créés.
Cela signifie qu'en pratique, il est possible de bloquer Tomcat pendant une durée inconnue.
Cela fonctionne également:
En fait, en définissant ce qui suit dans/etc/default/Tomcat7, j'allais bien:
Java_OPTS = "- Djava.security.egd = fichier:/dev /./ urandom -Djava.awt.headless = true -Xmx1024m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC"
Commentaire de:
En utilisant /dev/urandom comme la source d'entropie est une solution de contournement qui réduit le temps de démarrage de Tomcat, ce n'est pas une bonne idée car cela peut avoir des effets secondaires involontaires.
D'autres composants exécutés sur le serveur Tomcat (par exemple, des applications Web) peuvent dépendre d'une instance SecureRandom correctement initialisée et il peut y avoir des problèmes de sécurité lorsque l'entropie pour les nombres aléatoires n'est pas suffisante.
En fait, c'est l'une des raisons pour lesquelles l'utilisation de /dev/urandom ne fonctionne pas, mais /dev/./urandom Est-ce que. Le SHA1PRNG s'appuie fortement sur une bonne graine. Si la graine n'est pas bonne, les nombres aléatoires sont prévisibles. Par conséquent, le développeur s'est assuré qu'à cette fin /dev/random est utilisé comme source d'entropie, même si la JVM est configurée pour utiliser /dev/urandom. Il y a deux rapports de bogues à ce sujet ( bug 1 , bug 2 ).
Donc, au lieu de changer la source d'entropie en /dev/urandom, il faut plutôt s'assurer que /dev/random a suffisamment d'entropie. Si le système possède un RNG matériel, l'installation de rng-tools devrait faire l'affaire. Sinon, l'installation de haveged fournit une très bonne source d'entropie qui ne dépend pas d'un RNG matériel spécial pour être présent. Dans une machine virtuelle, rng-tools peut utiliser l'entropie de l'hôte via un RNG matériel virtuel. Comme alternative à cela, EGD pourrait être utilisé, mais pour le moment ce logiciel n'est pas inclus dans les référentiels Ubuntu, de sorte qu'il est gênant de l'utiliser .