Incohérence dans les tailles [Résolu]

[ram-0000]

Bonjour,

Sur une machine Solaris Sun SPARC

Code :

1
2
# uname -a
SunOS myname 5.10 Generic_142909-17 sun4u sparc SUNW,SPARC-Enterprise

J'ai un problème de cohérence dans les tailles de fichiers et l'espace disponible sur le disque :

Le fichier d'abord :

Code :

1
2
# ls -alh catalina.out
-rw-r--r--   1 root     root         40G Jan  3 10:25 catalina.out

Il s'agit du fichier de log d'un serveur WWW Tomcat. Le fichier est énorme (40GO) et on ne peut pas arrêter ce serveur comme cela (appli en prod).

Ce fichier se trouve sur la partition /opt et la taille de cette partition est la suivante :

Code :

1
2
3
4
5
# df -kh
Filesystem             size   used  avail capacity  Mounted on
...
/dev/md/dsk/d113        38G    16G    22G    44%    /opt
...

Si on récapitule, le fichier fait 40GO et il se trouve sur une partition qui fait 38GO remplie à 44%. Il y a donc incohérence et je ne sais pas dire qui a raison (df ou ls) (bien que je pense que df soit juste car le système continue à fonctionner normalement).

En ce qui concerne la cause de ce problème, je pense que c'est à cause d'une manipulation que l'on fait sur le fichier catalina.out. Pour le remettre à zero, on passe la commande

Code :

 > catalina.out

alors que le serveur WWW est encore actif (on ne peut pas l'arrêter).

Pendant quelque secondes après l'exécution de cette commande, la taille du fichier est à 0, l'espace occupe sur le disque diminue (vu avec df) puis la taille du fichier repasse à son ancienne taille (mais l'espace occupé sur le disque ne remonte pas).

Mes questions donc :

• Quelqu'un a t'il déjà rencontré ce comportement, ce problème d'incohérence est il un bug sur Solaris.
  
• Quelqu'un sait-il remettre vraiment à 0 la taille du fichier catalina.out sans arrêter le serveur Tomcat.

Merci d'avance

[frp31]

le fichier continue à être alimenté à grande vitesse, donc la seule solution est l'arrêt de l'application ...
l'analyse du problème
et le redémarrage de l'application

en cas de problème après ça, (reproductibilité), il faudra voir si c'est pas le FS qui pose problème, ou encore l'application elle même mal codée mal écrite qui devient folle est continue d'écrire dans le fichier.


dumoins c'est le coup "classique" avec ces symptômes.

[ram-0000]

Envoyé par frp31

le fichier continue à être alimenté à grande vitesse,

Alimenté oui, à grande vitesse, c'est quelques logs par secondes (donc pas vraiment du grande vitesse).

Envoyé par frp31

donc la seule solution est l'arrêt de l'application ...

Oui mais c'est interdit (du moins, pas autorisé comme cela)

Envoyé par frp31

en cas de problème après ça, (reproductibilité), il faudra voir si c'est pas le FS qui pose problème,

Ce problème est reproductible (et reproduit) sur une autre SUN (probablement même version d'OS) toujours avec Tomcat. Je penche (attention à pas tomber) aussi pour un problème/bug du FS.

Envoyé par frp31

ou encore l'application elle même mal codée mal écrite qui devient folle est continue d'écrire dans le fichier.

J'ai l'impression que Tomcat utilise le module log4j pour journaliser.

[jlliagre]

Envoyé par ram-0000

Si on récapitule, le fichier fait 40GO et il se trouve sur une partition qui fait 38GO remplie à 44%. Il y a donc incohérence et je ne sais pas dire qui a raison (df ou ls) (bien que je pense que df soit juste car le système continue à fonctionner normalement).

Il n'y a pas d'incohérence. Les deux informations sont correctes.

En ce qui concerne la cause de ce problème, je pense que c'est à cause d'une manipulation que l'on fait sur le fichier catalina.out. Pour le remettre à zero, on passe la commande

Code :

 > catalina.out

alors que le serveur WWW est encore actif (on ne peut pas l'arrêter).

Exact. C'est bien la cause de cette différence.

Quelqu'un a t'il déjà rencontré ce comportement, ce problème d'incohérence est il un bug sur Solaris.

Ce n'est pas un bug mais le comportement normal d'un système de fichiers Unix.

Quelqu'un sait-il remettre vraiment à 0 la taille du fichier catalina.out sans arrêter le serveur Tomcat.

Ce n'est pas possible. Le code qui écrit les logs fait un seek à la position attendue dans le fichier de logs avant d'écrire une nouvelle ligne. Le fichier n'occupe pas plus d'espace disque, il s'agit d'un sparse file.

[ram-0000]

Merci pour le sparse file, c'était effectivement cela (et d'un autre côté, cela me rassure sur ma santé mentale )