Tomcat s'arrête automatiquement
J'utilise Apache et Tomcat sur un serveur Windows et depuis ce matin, Tomcat cesse de fonctionner sans aucun journal. Il ne pend pas, il a juste fermé.
Il n'y a pas de journal dans Tomcat, le processeur/la mémoire sont des amendes, il n'y a pas de System.Exit dans mon code.
Quelqu'un a déjà eu ce problème?
Cela se passe au hasard, après 5-10 minutes. L'application répond normalement et parfois, boom .. cesse de fonctionner.
MISE À JOUR: Toujours pas la moindre idée. L'équipe d'administration installera l'application Web sur une autre boîte ...
J'ai eu ce problème, et j'ai trouvé la cause à ce link . Mon script pour démarrer Tomcat avait la dernière ligne tail -f catalina.out. Parfois, je n'ai pas tué ce script, le shell a ensuite dépassé le délai imparti et l'a tué avec tous les processus enfants, y compris Tomcat.
Cela ressemble à la JVM se bloque. Avez-vous cherché un journal des incidents JVM? Il porte généralement le nom hs_err_pid * .log et est créé dans le répertoire de travail de la machine virtuelle.
Si vous trouvez un fichier comme celui-ci et le téléchargez, nous pourrons probablement vous aider davantage.
Quelques questions:
- Avez-vous récemment changé la version de Java que vous utilisez?
- Quelle est la version exacte de Tomcat que vous utilisez?
- Utilisez-vous Tomcat Native (Apache Portable Runtime)?
Récemment, j'ai eu ce problème. Si quelqu'un devait faire face au même problème à l'avenir, j'espère que cela aidera.
Scénario: Tomcat s'arrête sans journaux ni erreurs
Cause principale de mon problème: méthode synchronisée accessible à partir d'une tâche à l'aide de TimerTask
J'avais une classe singleton avec une méthode synchronisée accessible à partir de divers threads en fonction du timer ou de l'action de l'utilisateur . Parfois, cette méthode peut prendre jusqu'à quelques minutes. Lorsque TimerTask attend cette méthode pendant un certain temps (le délai est écoulé, le thread est arrêté ou quelque chose se passe en arrière-plan) et dès que le verrou sur la méthode est relâché, Tomcat est tué.
J'ai donc supprimé le mot clé synchronisé, le singleton et quelques modifications de code pour la sécurité des threads. Alors le problème est parti.
Comment j'ai découvert: J'ai eu une instruction de journal dans la première ligne de la méthode synchronisée et à chaque fois que Tomcat s'arrête, j'ai trouvé ce message dans les dernières lignes.
Cordialement, Phanindra Kasturi
choses à rechercher dans le débogage d'un problème comme celui-ci:
- Examinez le répertoire des journaux ($ Tomcat_ROOT/logs) pour vous assurer qu'aucun des fichiers de journal ne contient de trace de pile.
- Examinez le script de démarrage de Tomcat pour vérifier l'emplacement des fichiers journaux afin de déterminer si les journaux ne sont pas en cours d'écriture dans un autre répertoire.
- Une autre raison pourrait être qu'un autre utilisateur/processus pourrait émettre un kill -9 qui pourrait tuer Tomcat sans lui donner la moindre chance de consigner des erreurs.
A fait face à ce problème récemment.
Scénario : Tomcat a démarré correctement mais est automatiquement arrêté au bout d'une heure. Parfois, cela se produit au bout d'un jour et rien ne figure dans les journaux de Tomcat.
Issue : Le problème réel était l'utilisation intensive de la mémoire et l'absence de mémoire SWAP libre.
Comment j'ai trouvé la solution
Si Tomcat n’affiche aucun journal, il doit y avoir quelque chose dans les journaux système. J’ai donc coché /var/log/messages, mais l’autorisation refusée pour moi j’ai essayé /var/log/dmesg et je l’ai obtenu.
"Manque de mémoire: Kill process 14606 (Java) marque 106 ou sacrifie l'enfant".
Dans la sortie, j'ai remarqué Swap Memory free 0 K . Ran top commande pour confirmer la même chose. Il y a donc eu une utilisation importante de la mémoire, ce qui a amené le système d'exploitation à tuer mon processus Tomcat.
Après avoir passé des heures, j'ai enfin compris la raison.
ps -ef | grep Tomcat a montré que plusieurs processus Tomcat étaient en cours d'exécution pour la même application. Il semble que les arrêts antérieurs de Tomcat n’aient peut-être pas abouti et que les processus n’aient pas été arrêtés, même après l’arrêt, pour une raison quelconque, ce qui entraînait une utilisation importante de la mémoire.
Ainsi, tous les processus Tomcat en cours d'exécution ont été supprimés à l'aide de kill. La mémoire SWAP a été libérée.
A commencé Tomcat à nouveau, a bien fonctionné. :)
J'ai remarqué CATALINA_OPTS sur mon chemin et cela était défini pour une taille de machine virtuelle inférieure. Par conséquent, le plantage et aucune trace de journal de Tomcat n’a été trouvée. Le serveur s’arrête automatiquement en moins de 2 heures.
vérifiez, CATALINA_OPTS ou Java_OPTS - ceux-ci peuvent avoir des paramètres JVM. augmentez-les ou commentez-les et augmentez la mémoire d'échange.
une autre possibilité est qu'un processus ait été démarré ce matin sur la boîte liée à un port requis par votre serveur.
“Le service sur l'ordinateur local a démarré puis s'est arrêté. Certains services s'arrêtent automatiquement s'ils ne sont pas utilisés par d'autres services ou programmes.”
J'ai parcouru le problème. J'ai essayé de nombreuses façons de sortir du problème. J'ai finalement trouvé la solution suivante.
1) Cliquez sur Exécuter Commande depuis le bouton de démarrage.
2) Entrez Services.msc puis cliquez sur OK, vous obtiendrez tous les services sur votre ordinateur.
3) Sélectionnez votre service et cliquez avec le bouton droit sur le service et sélectionnez Propriétés
4) Goto Logon Properties et sélectionnez Compte système local puis cliquez sur OK.
Cela fonctionnera.
Parfois, cela se produit si un autre programme est exécuté sur le même port. Par exemple, Skype. Fermez ce programme avant de démarrer Tomcat.
Vos servlets ou l'une de ses dépendances sont-ils autorisés à appeler System.exit ()? (Vous ne savez pas comment les machines virtuelles Tomcat sont verrouillées dans ce sens)
Des développeurs ont pensé qu'il était correct d'utiliser exit (666); lors de la détection d’une matrice non invertable (ce qui n’est pas bon, mais certainement pas fatal). Arrgh. Peut-être que vous avez un coupable similaire dans votre système?