Discussion :

[T.NightGlow]

Bonjour,

Je cherche un moyen de forcer la rotation des fichiers de log standards de Tomcat (stdout et stderr, principalement), sans redémarrer le serveur (bien entendu).
Ceci avec la version 5.5 de notre cher serveur d'application supporté par Windows (oui... je sais, la rotation est tellement plus simple à faire avec une tâche cron sur linux... )

Merci d'avance

[tchize_]

Pour faire tourner les logs de tomcat, il faut configurer d'abord tomcat pour utiliser, par exemple, log4j: http://tomcat.apache.org/tomcat-5.5-doc/logging.html ensuite, il faut configurer log4j pour faire de la rotation de logs (voir les docs de log4j).
Enfin, il faut savoir que cela fera tourner les logs de tomcat utilisant les mecanisme de logging. Tout le code de tomcat le fait. Par contre, si t'as des webapps mal foutues qui font du System.out ou du System.err, çà terminera toujours dans catalina.out. Ce genre d'application est une plaie à gérer d'habitude .

Enfin, comme le catalina.out, c'est la redirection de stdout et stderr ET que cette redirection est faite *en dehors de tomcat* (utilisaition des opérateur > et &2>1 sous linux par exemple), il est impossible de faire tourner le log. Même avec un cron extérieur sous linux c'est pas possible sans arrêter tomcat, puisque le handle vers le fichier ouvert n'est par relaché par le shell ayant lancé tomcat

[T.NightGlow]

Bonjour,

Merci pour ta réponse.
Par contre, étant sur Tomcat 5.5 et sous Windows, je n'ai pas de catalina.out mais deux fichiers stdout_AAAAMMJJ.log et stderr_AAAAMMJJ.log...

Dans mon cas, c'est le premier (stdout_AAAAMMJJ.log) qui gonfle, justement à cause de System.out.

Ces fichiers effectuent naturellement une rotation au démarrage du serveur, mais pour mon client, chez qui le serveur tourne en permanence, cela ne peut être satisfait (même en considérant un redémarrage programmé pendant la nuit).

Je continue à chercher, donc...

Merci d'avance s'il y a d'autres réponses

[tchize_]

Pas le choix, va falloir que tu corrige la webapp qui utilise le stdout impunément

[T.NightGlow]

On a toujours le choix Surtout en programmation ^^
Faut juste assumer les conséquences

Bon, donc, j'ai trouvé plusieurs possibilités, je n'ai pas tout pousser à fond, mais, au menu :
- Utiliser un package de logging comme log4j et l'option swallowOutput (pas vraiment testé, car j'ai pas réussi à identifier comment rediriger le flux)
- Redémarrer le serveur d'application à une heure régulière (Tomcat 5.5 fait la rotation automatiquement, dans ce cas), de préférence la nuit (mais cela n'est pas toujours possible en fonction du service rendu par la machine)
- Tenter le système de cronlog proposé sur certains sites (compatible qu'avec linux et risque de IOException car le handle sur le fichier reste normalement ouvert...)
- Rediriger les flux vers des fichiers (System.setOut et System.setErr)

C'est la dernière solution que j'ai choisi (ça évite de redémarrer le serveur, il n'y a qu'à compiler une classe et recharger l'application).
Compatible avec windows et linux, pas d'exception sortie.
Seul problème : les handles sur les fichiers créés par Tomcat (au démarrage du serveur) restent ouverts (mais inutilisés... je vais voir s'il y a pas moyen de les libérer), par contre, les handles sur les fichiers que mon script créent se referment tous les jours au bon moment.

Donc, dans ma classe, j'ai ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public static String _date=Utiles.fromDateToMySQL(Calendar.getInstance()).replaceAll("-","");
 
  public static void refresh(){
    if(!_date.equals(Utiles.fromDateToMySQL(Calendar.getInstance()).replaceAll("-",""))){
      _date=Utiles.fromDateToMySQL(Calendar.getInstance()).replaceAll("-","");
      try{
        System.setOut(new PrintStream(new FileOutputStream("logs"+File.separator+"stdout_"+_date+".log")));
        System.setErr(new PrintStream(new FileOutputStream("logs"+File.separator+"stderr_"+_date+".log")));
      }catch(Exception e){
        //?
      }
    }
  }

Ah oui... et pourquoi je peux pas aller changer les abus de System.out partout : J'utilise l'API Javamail qui écrit ses débug sur la sortie standard... donc à moins de la modifier et la recompiler (ce que je n'ai ni le temps ni l'envie), je préfère rediriger la sortie
(Maintenant que j'y pense, y'a ptet un moyen de faire faire les logs de Javamail ailleurs que sur la sortie standard... tant pix ^^)

En tout cas, m'ci de ton aide et de ton attention

[tchize_]

Ah oui... et pourquoi je peux pas aller changer les abus de System.out partout : J'utilise l'API Javamail qui écrit ses débug sur la sortie standard... donc à moins de la modifier et la recompiler (ce que je n'ai ni le temps ni l'envie), je préfère rediriger la sortie
(Maintenant que j'y pense, y'a ptet un moyen de faire faire les logs de Javamail ailleurs que sur la sortie standard... tant pix ^^)

En tout cas, m'ci de ton aide et de ton attention

C'est vrai, on a toujours le choix. Ton truc du system.out, je le connaissait autrement. Nous aussi on a une surcharge des out / err, mais pas pour les même raisons :p On a une webapp qui dépend d'une librairie buggé qui essaie de fait un System.out.close(). Ceci est très efficace si tu veux faire taire ton application au passage

Pour l'api javamail, on utilise javamail ici aussi, il n'attaque pas System.out directement, çà utilise java.util.logging. Y a des doc sur le net sur comment rediriger util/logging sur log4J, par exemple.

[T.NightGlow]

Effectivement, j'ai pas été voir très loin pour javamail lol

La redirection sur log4j, je l'avais trouvé, mais j'ai pas percuté que Javamail utilisait util.logging... ça m'apprendra à pas me renseigner plus loin

Encore merci