panne systematique au bout de 24 jours sous red-hat 4.5

Bonjour
J'ai un problème avec une application sous linux red hat entreprise 4.5 (noyau 2.6.9) : au bout de 24 jours de fonctionnement, celle-ci tombe systématiquement en panne pour une raison indéterminée.
Bien sûr j'ai immédiatement soupçonné l'application mais malgré mes multiples recherches je ne vois aucune anomalie : j'ai vérifié qu'il n'y avait pas de fuite mémoire (avec valgrind), j'ai relu le code et vérifié qu'il n'y avait pas de timer qui claquerait au bout de 24 jours...
J'ai fait plusieurs essais (en attendant donc à chaque fois 24 jours), et l'application cesse systématiquement de fonctionner au bout de cette période. Je précise qu'elle ne plante pas puisque l'appli apparait toujours en lançant la commande "ps -ef" par exemple.
Par contre je suis incapable de reproduire le pb en accéléré (par ex en changeant la date avec un script qui fait avancer de 55 minutes toutes les 5 minutes, afin de simuler en accéléré le comportement de mon application) ou en augmentant le nombre d'actions quotidiennes afin de tomber plus vite dans le problème. C'est toujours 24 jours quoiqu'il se passe.
Pour info, la machine sur laquelle tourne mon appli est déconnectée d'internet donc inutile de chercher par là...
Je tiens également à préciser que le problème n'apparait pas sous red-hat 7.2 (noyau 2.4.17)
Du coup j'en viens à soupçonner le système Linux lui-même qui viendrait embrouiller l'appli au bout de 24 jours, mais manquant d'expérience sur ce système, je ne vois pas du tout lequel...
Existe-il des timer dans le noyau susceptibles de claquer au bout de 24 jours?
Avez vous connaissance de cas similaires ou une appli tombe en panne au bout d'un certain temps sans raison apparente?
Merci d'avance pour vos réponses!

Peux tu préciser si ton appli :
- plante au bout de 24 jours d'activité (donc 24 Jours après son démarrage)
- ou si c 'est toujours a J+24 (donc même si elle n'est active que depuis 10 jours - donc 14 jours sans l'appli active depuis le plantage)

Regarde également dans les taches cron ou equivalent
et bien sur du coté de la base de données si tu en utilise une.

Merci pour ton message rberthou

En fait je n'ai pas encore fait le test car j'ai toujours lancé l'appli en même temps que je démarrais la machine... mais ton idée est intéressante car elle permettrait de savoir de quel côté se situe le pb :
- si je démarre la machine au jour J et l'appli à J+10 et qu'elle tombe en panne à J+24, le système est en cause
- si elle tombe en panne à J+34, l'appli est en cause.

J'ai examiné les taches de cron mais je n'ai rien trouvé d'intéressant. Qu'entends tu par équivalent de cron?

J'utilise une base de données (postgres) mais je ne vois pas en quoi elle pourrait poser problème. Pourrais tu préciser ton idée?

Merci

Équivalent du cron je pense principalement à certain sheduler maison (style Quartz, ou dev 100% interne) de plus certaine base de donénes ont leur propre scheduler (DB2 par exemple).

Concernant la base de données vérifie si par exemple tu n'a pas un job de Backup qui ferme la base mais ne l'ouvre pas (ou mal) . Ou un trop grand nombre de connexions (la je ne verrai pas le problème cyclique).
Vérifie si la base de données est toujours OK quand ton appli est KO (de preference avec un tit programme de tests utilisant les mêmes connexions).

Après une bonne petite recherche, je n'ai pas trouvé de scheduler maison.

Concernant la base de données, l'appli se connecte une seule fois à elle au démarrage. Ensuite on utilise l'identifiant de connexion pour lancer les requêtes. Ceci élimine donc la piste du nombre max de connexions. Par contre je me suis demandé s'il n'y avait pas un timer caché dans postgresql qui fermerait la base de données après un certain temps, mais je n'ai rien trouvé à ce sujet.

J'ai une machine qui doit tomber dans le problème vendredi, je vérifierai la disponibilité et le bon fonctionnement de la base de données une fois l'appli bloquée

Merci pour ton aide en tout cas

Il ne doit pas avoir de timer qui ferme l aabse de données mais par contre un timer sur la connexion est fort possible.

Si tu prend une seule connexion ajoute dans on code un test ou trace te permettant de traiter le cas ou celle ci est close ou HS .

Comme prévu, le problème s'est bien reproduit aujourd'hui.
Il semblerait que l'un des composants ne réponde plus, d'ailleurs la tâche correspondante n'apparait plus en faisant un ps -ef (chose que je n'avais pas identifiée lors de mes analyses précédentes)
De plus on tombe dans le problème au bout d'environ 24 jours et 20 heures
Or 0x7FFFFFFF ça fait exactement 24j 20h 31min 23s si on compte en millisecondes. Ça m'étonnerait fort que ce soit une simple coïncidence et je vais aller chercher un compteur entier signé sur ce composant!

Je pense donc qu'il s'agit d'un pb applicatif et non d'un pb système, il serait peut être bon de déplacer mon message dans un sous-forum plus approprié (je n'ai pas trouvé comment faire...)

Bonjour

Je relance ma question avec de nouvelles informations :
1) En effectuant un "ps -ef", j'ai remarqué qu'il y a 3 .exe qui ont disparu après l'apparition du problème. Il est quasiment certain que leur disparition est la cause du problème de blocage. Il me faut donc maintenant comprendre pourquoi ils ont disparu.
Malheureusement il n'y a pas eu de core généré, je pensais (certainement à tort) que toute application qui plantait devait générer un core... Y a-t il des conditions particulières où le plantage ne génère pas de core?

2) Dans la mesure où le temps au bout duquel le problème apparait est constant (24 jours, 20h et environ 31 minutes), je me suis intéressé aux différents tics d'horloge sous linux, et en particulier aux "jiffies". Je n'ai malheureusement pas trouvé d'information concordante sur la durée exacte qà laquelle correspond un incrément de jiffies (4ms semble être la réponse la plus fréquente, j'ai aussi trouvé 10ms ou 1/1024 seconde). Je n'ai pas non plus trouvé son format (int, long, double?). En fait je cherche quel pourrait être le compteur de temps qui serait initialisé au démarrage de la machine (jiffies correspond bien à ce cas) et qui serait incrémenté de telle manière qu'il dépasse la valeur max de son format au bout de 24j 20h et 31 min. Ceci correspondrait à un compteur en millisecondes défini sur un int ou un long signé qui passerait en négatif lorsqu'on atteint 7FFFFFFF. Savez vous si un tel compteur existe? Quid de jiffies?

3) Une dernière précision : j'ai le problème en reh hat 2.6.9-55 mais je n'ai pas le problème en red hat 2.4 (mais sur une machine différente). Le problème peut donc être lié au changement d'OS ou au hardware (j'ai en particulier lu que jiffies pouvait dépendre du hard)

Merci pour vos réponses

Bonjour
Le problème est résolu : il y a un bug dans la méthode setitimer du noyau 2.6.9-55 : lorsqu'on arme une tempo, celle-ci est écrêtée à la valeur 7FFFFFFF. Ceci correspond au nombre de claquement de jiffies, ce qui dans le cas d'un jiffies=1ms donne une durée max de 24 jours 20h et 31 minutes.
Ce bug n'est pas présent dans les versions ultérieures du noyau (au moins à partir de la 2.6.18)
Vu la qualité de ce forum je me devais d'apporter la réponse à ma question, c'est bien normal! :D