Tomcat 6 Log4J - Linux - Safely Remove Catalina.Out

Tomcat 6 log4j - linux - safely remove catalina.out

Tomcat redirects its stdout and stderr to catalina.out. So direct out/err writes and log4j ConsoleAppender messages will go to catalina.out. See catalina.sh file for details. To disable it completely you can redirect stdout and stderr to /dev/null setting CATALINA_OUT environment variable:

export CATALINA_OUT=/dev/null

But I recommend to disable ConsoleAppender instead to reduce catalina.out size and monitor it periodically looking for error messages, that may go to stdout bypassing log4j.

Turn off logging to catalina.out

Solution: configured to log to /dev/null

Log4j logging in catalina-date.log

If you want to rotate logs/catalina.out on win32 when using the startup scripts to launch Tomcat, one option is to install a log-ratating logger such as chronolog (which might be a *NIX-only thing) and then modify catalina.out to pipe standard output to that process instead of redirecting to a file.

Update: A better option (in general on win32) is probably to use Tomcat's service installer and run Tomcat as a service, but I don't believe it makes things any easier to rotate your log file.

The best option of course is not to write to standard out in the first place to avoid ever needing to rotate this log file.

catalina.out rolling with Tomcat 6.0

Fixed it, turns out the standard logging configuration defines a file logger and also a console logger. The file logger goes to the daily catalina log, and the console logger writes to catalina.out.

Fix was to change in conf/logging.properties:

.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

to

.handlers = 1catalina.org.apache.juli.FileHandler

That stops anything getting written to catalina.out

Tomcat catalina.out is 40GB

catalina.out reaches such a large size because:

1- there might be many logging messages sent to console handler, and

2- also there is not any rotation of catalina.out (and no policy to remove older catalina.out).

First, as there might be some duplication and the messages in catalina.out , which could also be stored in *log messages too, I'd check if the contents of the log files (catalina.[DATE].log) are the same as those of catalina.out, if so then you can edit file conf/logging.properties and remove console handler

I'd also check the level of the log messages and set a higher level if possible. Look for this line in conf/logging.properties

java.util.logging.ConsoleHandler.level = ....

Possible levels, in increasing level of frequency are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL. I'd try replace ALL, FINEST, FINER, FINE by CONFIG or even INFO. For instance, by setting it to INFO, all SEVERE, WARNING and INFO messages will be logged but not any with a level to the right of that list.

Also another option is set a limit to console handler by adding this line to conf/logging.properties

java.util.logging.ConsoleHandler.limit = 1024000

and rotate catalina.out configuring an automatic task to remove older ones.

Log4j daily rolling catalina.out without restarting Tomcat?

There are three solutions for this problem:

  1. change default tomcat logging façade that writes to catalina.out to for example: slf4j, with all the benefits that comes with using it and log4j.
  2. configure system cron to run logrotate of tomcat log files
  3. change default logging class from ConsoleAppender to FileAppender.

Benefits of solutions:

  1. very flexible as the slf4j offers many options especially with log4j, that you use anyway.
  2. simple and doesn't require touching tomcat configuration.
  3. simple change of configuration that disables console output

Disadvantages:

  1. require additional libraries, affects all applications that tomcat is hosting, requires replacing default configuration with log4j.
  2. cron+logrotate works only in linux; it might be not as simple in windows with scheduler. Requires extra scripting in windows environment.
  3. provides only simple backup with date. Date pattern cannot be set. Does not compress rotated files.

    Solution for First issue, is described here

    Solution for Second issue is described here

    Solution for Third issue is described here

You can as well combine solutions. For example use crontab to gzip files that where created by changing catalina.out to other name.
I would also suggest to leave tomcat so it logs to catalina.out, and configure your application to different file with log4j. This way logs from tomcat that are not immaterial won't spam your logs.

Log4J intergration with Tomcat - catalina.out log file rotation

You misunderstand how catalina.out is created. It's not handled by a logging framework like log4j. It's created by the shell through redirection of the standard output stream.

If you want to rotate it, check the Tomcat FAQ.

There's also this previous answer.

Tomcat logging in webapp and container?

It seems this configuration is ignored by tomcat.

Try to recheck your tomcat setup, these config steps are not simple, but definitely works after done exactly as they stated.

After that you will have your container level log config in $CATALINA_HOME/lib/log4j.properties.
So to control tomcat's itself output you can add lines like these:

log4j.logger.org.apache.tomcat=INFO
log4j.logger.org.apache.catalina=INFO
log4j.logger.org.apache.coyote=INFO

Concerning catalina.out file - see this SO answer.



Related Topics



Leave a reply



Submit