Summary: | init script for www-servers/tomcat-7.0.32 drops STDOUT and STDERR | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Breuer <gentoo> |
Component: | [OLD] Server | Assignee: | Java team <java> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | via-gentoo |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to redirect STDOUT/STDERR into $CATALINA_OUT / $CATALINA_ERR |
This is a problem for me, as well. For example, I can't use slf4j-simple for logging purposes without additional configuration. *** This bug has been marked as a duplicate of bug 451140 *** |
Created attachment 338860 [details] Patch to redirect STDOUT/STDERR into $CATALINA_OUT / $CATALINA_ERR The current init script for www-servers/tomcat-7.0.32 (installed in /usr/share/tomcat-7/gentoo/tomcat.init, managed by /usr/share/tomcat-7/gentoo/tomcat-instance-manager.bash) causes tomcat's STDOUT and STDERR to be lost. This makes debugging certain issues (like: why does my log setup not work/the app not start at all?) quite frustrating. Upstream's catalina.sh by default redirects STDOUT and STDERR of the server process to .../logs/catalina.out. I've attached a patch which enables this behavior in the tomcat.init script, by introducing new configurations variables "CATALINA_OUT" and "CATALINA_ERR". While doing this, I've split STDOUT and STDERR into separate targets. I *think* there should be no problem redirecting them both into the same file; but I haven't tried that. The new variables could be accompanied by some descriptive text in the config file template (/usr/share/tomcat-7/gentoo/tomcat.conf): --------------------------------------------------------- # File locations for the server's STDOUT and STDERR # if unset/empty, the respective output channel is lost # #CATALINA_OUT="/var/log/@INSTANCE_NAME@/catalina.out" #CATALINA_ERR="/var/log/@INSTANCE_NAME@/catalina.err" --------------------------------------------------------- I'm not too familiar with what parts of bash syntax are considered "good" or "bad" in init scripts, so I'd suggest someone with the appropriate init-script-fu looks over the patch before it gets applied.