Pourquoi JBoss et Logrotate créent-ils des files journaux remplis de caractères NUL?

J'ai configuré Logrotate pour faire pivoter mes journaux JBoss Application Server 4.2.2.GA tous les soirs. Une fois que les files journaux ont été tournés et JBoss commence à les écrire à nouveau, les nouveaux files journaux commencent avec autant de caractères NUL que de caractères dans le file journal précédent, suivis des nouveaux messages de journal. Par exemple, si le file JBoss server.log avait 5000 octets de long, après la rotation, le nouveau file server.log commencera avec 5000 caractères NUL. Après plusieurs jours, server.log commence par des caractères NUL équivalents aux caractères dans tous les jours précédents, les files journaux sont combinés. Il semblerait que JBoss se souvienne de sa position dans le file journal et qu'il retire là où il s'est arrêté dans le file tronqué. Voici ma configuration logrotate pour JBoss:

/apps/jboss-4.2.2.GA/server/default/log/*log { daily rotate 30 compress notifempty copytruncate missingok nocreate } 

Je ne peux pas redémarrer JBoss tous les soirs parce que ce serait trop de time d'arrêt. Je ne peux pas non plus utiliser Log4j DailyRollingFileAppender car il ne supprime pas les anciens files journaux. Est-ce que quelqu'un a commencé à fonctionner correctement avec JBoss?

Nous avons eu le même problème pour un file écrit par log4j. La solution était de définir la propriété "Ajouter" pour que FileAppender soit "vraie". Après ce changement, nous n'avons pas vu ce problème avec les files ayant NUL lors d'une rotation par un programme externe comme logrotate.

De mon expérience – et la raison pour laquelle nous n'utilisons pas logrotate avec Log4j, c'est que la façon dont fonctionne logrotate est qu'elle renomme les files, puis indique au programme de fermer ses journaux et de les rouvrir avec l'ancien nom de file (ce qui n'existe plus ), en utilisant normalement le signal HUP.

Mais Log4j ne peut pas être invité à rouvrir ses files journaux, alors je vois que vous utilisez copytruncate pour copyr les files à la place – le problème est que Log4j utilise des écrivains tamponnés qui surveillent la position actuelle du file qui est en cours d'écriture et lorsque vous tronquez le file. le file journal log4j continue à écrire d'où il a cessé d'écrire avant le tronçon. Selon l'implémentation de votre système de files, cela devrait créer des "files avec des trous" – c'est-à-dire que les caractères NULL que vous voyez là n'existent pas vraiment – le file n'est en réalité que aussi grand que datatables réelles et le caractère NULL est la façon dont votre visionneuse représente le trou. Certains filesystems, en revanche, ne supportent pas les trous et complètent le file avec des caractères NULL lorsque Log4j reprend l'écriture.

Je suggère – n'utilisez pas logrotate, searchz un moyen de faire pivoter les files dans Log4j en utilisant un RollingFileAppender (qui prend en charge la suppression des anciens files) ou en utilisant DailyRollingFileAppender et un cronjob qui supprime les anciens files à l'extérieur (comme cela devait être fait ).