Bug 53930 - allow capture of catalina stdout/stderr to a command instead of just a file [PATCH]
Summary: allow capture of catalina stdout/stderr to a command instead of just a file [...
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.0.x-trunk
Hardware: Macintosh Mac OS X 10.4
: P2 enhancement with 13 votes (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2012-09-24 15:53 UTC by Casey Lucas
Modified: 2020-05-06 14:30 UTC (History)
2 users (show)



Attachments
patch to catalina.sh adding support for CATALINA_OUT_CMD (2.61 KB, patch)
2012-09-24 15:53 UTC, Casey Lucas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Casey Lucas 2012-09-24 15:53:47 UTC
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.
Comment 1 Christopher Schultz 2013-10-28 14:32:28 UTC
I'm not sure if this matters a lot, but the "touch $CATALINA_OUT" has been dropped from this patch. Was that intentional?
Comment 2 Casey Lucas 2013-10-28 16:29:14 UTC
(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.
Comment 3 peterhansson_se 2016-12-02 10:22:32 UTC
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.
Comment 4 peterhansson_se 2016-12-02 15:33:04 UTC
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.
Comment 5 Mark Thomas 2018-12-03 15:08:19 UTC
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
Comment 6 Konstantin Kolinko 2019-02-13 13:31:36 UTC
Note that a regression from this patch is being discussed in bug 63041.
Comment 7 Mark Thomas 2019-02-13 14:06:33 UTC
The original fix has been reverted due to regressions.
Comment 8 Mark Thomas 2019-02-13 14:11:18 UTC
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.
Comment 9 Mark Thomas 2019-03-22 17:14:30 UTC
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.
Comment 10 harald.dunkel 2020-05-05 12:42:08 UTC
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.
Comment 11 Christopher Schultz 2020-05-06 14:30:59 UTC
(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.