Suite à une mise à jour du serveur, je me suis aperçu que le serveur Tomcat n’était plus lancé.

La commande ps faux me confirmera qu’il ne se trouvait plus dans la liste des processus.

C’est finalement dans le fichier de log /var/log/syslog que se trouve le message d’erreur à propos du chargement de Tomcat :

jsvc.exec[5678]: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:139)

Une rapide recherche sur le net me conduira à nouveau vers le système de bugtracking de debian toujours aussi réactif !
Référence du ticket sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477363

Les informations importantes

Version de tomcat concernée: 5.5.26-1
Debian : Lenny
Package : tomcat5.5

Cause

jsvc ne trouve pas la librairie java commons-logging. (commons-logging-api-1.1.1.jar)

Solution

Ajouter le chemin de la librairie commons-logging dans le CLASSPATH de jsvc dans le script de démarrage de tomcat5 : /etc/init.d/tomcat5.5

Ce qui donne après modification la ligne suivante :

JSVC_CLASSPATH="/usr/share/java/commons-daemon.jar:
$CATALINA_HOME/bin/bootstrap.jar:
$CATALINA_HOME/bin/commons-logging-api.jar"

Merci à Michael Riedel pour ce correctif.
La prochaine version de Tomcat devrait prendre en compte cette modification. Vive la communauté Debian ^^

Ce matin, je me suis aperçu que le blog spiroid n’était plus en ligne. En cherchant la cause sur le serveur et en analysant les logs d’erreur d’apache j’ai trouvé la ligne suivante :

[crit] (28) No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed

Je me suis cependant assuré qu’il restait de la place sur le disque dur à l’aide de la commande ‘df‘. Après une rapide recherche sur internet, j’ai trouvé que je n’étais pas le seul avoir ce problème.

Rapport de bug

Le bug a été signalé sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450831

Les informations importantes :
Version d’apache concernée: 2.2.6-1
Debian : Lenny
Package : apache2-mpm-prefork

Cause

L’origine du problème pourrait venir de l’utilisation des sémaphores par le module rewrite (url rewriting).
On peut supposer qu’il s’agit d’un problème d’allocation mémoire.

Solution

Pas de patchs ni de correctifs ont été proposés pour le moment.

Solution temporaire

Pour débloquer la situation et libérer les ressources, entrez la commande suivante :
ipcs -s | grep www-data | awk ' { print $2 } ' | xargs ipcrm sem

Le problème est bloquant et risque de survenir après la rotation des logs configurée en général pour se produire chaque jour ou chaque semaine en temps normal. On peut ajouter temporairement la commande ci dessus dans les scripts de configuration de logrotate pour l’executer après chaque redémarrage d’apache lors des rotations de log (Non testé !)

A suivre …

EDIT : Corrigé depuis la version 2.2.8
EDIT : La correction du bug est prévue officiellement pour la version 2.2.9-3