Created attachment 29414 [details] patch to catalina.sh adding support for CATALINA_OUT_CMD catalina.sh currently supports passing in a value for CATALINA_OUT. If supplied the stdout/stderr of the java process will be redirected to this file. This single file scenario makes it difficult to keep file contents for long running process separated on a per day basis as is typical for production logging scenarios. We use cronolog (http://http://cronolog.org/) to do automatic log rolling but others may have different needs. The attached patch adds support to catalina.sh for an optional CATALINA_OUT_CMD variable. If this variable is defined, the stdout and stderr of the java process will be piped to the command. We use it as in: CATALINA_OUT_CMD="cronolog $CATALINA_BASE/logs/catalina.%Y-%m-%d.out >/dev/null 2>&1" export CATALINA_OUT_CMD catalina.sh start $@ Of course long-running, server-side applications should typically not be writing to stdout/stderr but sometimes this is out of your control.
I'm not sure if this matters a lot, but the "touch $CATALINA_OUT" has been dropped from this patch. Was that intentional?
(In reply to Christopher Schultz from comment #1) > I'm not sure if this matters a lot, but the "touch $CATALINA_OUT" has been > dropped from this patch. Was that intentional? I doubt it was intentional. However, the file should only be touched if will be used - basically, around line 380.
This is a very important addition. If you search the internet you'll find lots of recommendations on allowing log-rotation and all of them tell you to modify your catalina.sh file. The point here is that users really shouldn't modify catalina.sh as it breaks the upgrade path. Hence the feature should be supported in the script itself as per Casey's patch. Since this RFE was launched the catalina.sh script has been modified to also support NOHUP which means the Casey's patch no longer applies verbatim.
As a workaround: Use a copy-and-truncate strategy instead. This doesn't require changes to catalina.sh script. On Linux: Use logrotate utility with 'copytruncate' option. On Solaris: Use logadm utility with '-c' option. (or on Solaris 11 and later you can install logrotate by doing 'pkg install file/logrotate' if you really, really want to use logrotate instead of logadm) The proposed change basically allows for a pipe strategy. This strategy is better than a copy-and-truncate strategy for the following reasons: - The copy-and-truncate strategy requires extra disk space when the operation is being executed. - The copy-and-truncate strategy has a small time gap between the copy and the truncate. During the gap messages may be lost. - The copy-and-truncate strategy requires changes to setup outside of the Tomcat configuration: it requires changes to logrotate/logadm tool and potentially a new entry in cron table.
Thanks for the patch. Sorry it took so long to apply it. Fixed in: - trunk for 9.0.14 onwards - 8.5.x for 8.5.36 onwards - 7.0.x for 7.0.93 onwards
Note that a regression from this patch is being discussed in bug 63041.
The original fix has been reverted due to regressions.
The proposed patch causes problems for systemd users (and possibly others) that do not explicitly use CATALINA_PID to determine the PID of the started Tomcat process. Options: 1. Apply this patch as intended (e.g. r1848046) and document that systemd users need to explicitly use CATALINA_PID 2. Close as WONTFIX with the advice to use a named pipe in CATALINA_OUT if users want to pipe output to a process. 3. Add CATALINA_PIPE and CATALINA_OUT_CMD and manage creating of named pipe and creation of process to read from that pipe in catalina.sh 4. Something else? Personally, I'm leaning towards 2 at the moment.
The breakage for systemd users is of greater impact to the community than the lack of ability to pipe to a process. Therefore, there having been no further input I am proceeding with option 2 and closing this as WONTFIX with the recommendation to use a named pipe if you need this feature.
This is pretty disappointing. CATALINA_PID is part of the interface to manage tomcat. Anyway, logging to stdout and stderr is an anachronism, even for Java. The recommendation should be to set CATALINA_OUT to /dev/null and to use log4j or similar.
(In reply to harald.dunkel from comment #10) > This is pretty disappointing. CATALINA_PID is part of the interface to > manage tomcat. > > Anyway, logging to stdout and stderr is an anachronism, even for Java. The > recommendation should be to set CATALINA_OUT to /dev/null and to use log4j > or similar. And where do logs go before log4j(, etc.) is brought-up? Note that Tomcat doesn't log anything to stdout or stderr. It uses a proper logger through and through, which can be configured to go elsewhere.