Thank you so much Christopher for all that information. I will look in to the various options you've presented.
I have setup the logrotate using cron in the past and it was very successful on the Linux boxes but I could not find an equivalent setup for AIX. Things seem so much easier on Linux. The company wants a universal approach so that left that option out. I did see the section you copied in from the catalina.sh file but couldnt make much out from it so I left it alone. I like the sound of option b. I know where the context xml file is. (Under the Catalina/localhost/<context>.xml) Im not sure if this is what you mean by descriptor. If I did this would I leave the log4j config changes that I have in place that already? -Joleen On Nov 20, 2015 9:37 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: > Joleen, > > On 11/19/15 3:19 PM, Joleen Barker wrote: > > I want to say up front that I am not a developer and know enough to brake > > some stuff. lol > > Lots of "only admins" on this list. Welcome. > > > I have a software package from a vendor that ships the tomcat web server > > with it. Below are my environment details: > > > > 1) The tomcat version that is running is v8.0.26.0 > > 2) The OS is a Centos v7 UNIX VM > > 3) Java JDK I have installed that Tomcat is using is 1.8.0_60 > > 4) The vendor has the $CATALINA_HOME and CATALINA_BASE as the same > location > > which is <Install_directory>/server > > 5) The <Install_directory>/server directory is the place where the /lib, > > /bin, /conf, and etc.directory's are found. > > Thanks for providing all that information up front. > > > 6) Due to the catalina.out file growing too large with the default > > juli.AsyncFileHandler using the logging.properties file that was found in > > the $CATALINA_HOME/conf directory. I changed it to use the log4j logging. > > Here are the steps I did to make this happen which I found on Tomcat 8 > web > > site: > > > > a. Downloaded log4j-1.2.17.jar and placed it in > $CATALINA_HOME/lib > > b. Downloaded from the Tomcat extras web page for Tomcat 8 the > > tomcat-juli-adapters.jar and the tomcat-juli.jar. > > c. Deleted the old tomcat-juli.jar out of the > $CATALINA_HOME/bin > > directory. > > d. Placed the new tomcat-juli.jar file and the > > tomcat-juli-adapters.jar file in to the $CATALINA_HOME/bin directory. > > e. Deleted the old logging.properties file from the > > $CATALINA_HOME/conf directory. > > f. Created the log4j.properties file in the $CATALINA_HOME/lib > > directory and copied the settings that are shown on the Tomcat 8 logging > > web page that has been there for Tomcat 7 logging web page too that > > everyone is familiar with. Here is the url just incase: > > https://tomcat.apache.org/tomcat-8.0-doc/logging.html > > > > I know the log4j.properties files is being used as I made 2 changes to > the > > config file that were taken. One changes was to actually verify the > > log4j.properties file was being used, which was changed the word INFO to > > OFF for localhost file messages being written by editing the following > line > > at the bottom of the log4j.properties file: > > > > > log4j.logger.org.apache.catalina,core.ConainerBase.[Catalina].[localhost] = > > OFF, LOCALHOST > > > > The other change I made was I changed the file name in the following line > > to read catalina.out instead of catalina: > > log4j.appender,CATALINA.File = ${catalina.base}/logs/catalina.out > > > > The reason I did this was I thought the daily roll that was supposed to > > take place at midnight would occur on the file that was named catalina > and > > not on the file that was named catalina.out. All the INFO messages being > > written to the file named catalina were also being written to the > > catalina.out file which was the one I wanted to roll daily anyway so I > > thought this change would be fine. > > > > I stopped tomcat and cleared all the logs out and left the server to run > > over night. (It is still running now) and it appears the roll did not > take > > place. What I woke up to was everything you see below found in the > > $CATALINA_HOME/logs directory except for the one file written today which > > was due to me logging in to the web application that the vendor supports > so > > I could verify I could still login and use the software: > > > > -rw-r--r--. root root 33003 Nov 18 21:03 catalina.out > > -rw-r--r--. root root 0 Nov 18 21:03 host-manager > > -rw-r--r--. root root 0 Nov 18 21:03 localhost > > -rw-r--r--. root root 0 Nov 18 21:03 > > localhost_access_log.2015-11-18.txt > > -rw-r--r--. root root 2498 Nov 19 13:23 > > localhost_access_log.2015-11-19.txt > > -rw-r--r--. root root 0 Nov 18 21:03 manager > > > > I don't know what I am missing from the configs to make the catalina.out > > file roll each day at midnight. Some help would be greatly appreciated. > > You did a great investigation and (nearly) all the steps you took were > reasonable. Unfortunately, switching from JULI to Log4j isn't going to > fix this problem, and neither of those packages will save you from the > catalina.out non-rotation problem. (See below) > > > Also, no I cannot contact the vendor as they just tell me to hire a > > professional. So I am the professional. > > Wow. I wouldn't pay them any more money for anything. :( > > > And, no I don't want to use the RollingFileAppender as I need the roll > over > > to be based on day and not the size of catalina.out. > > > > I do see when the application starts and in the catalina.out it records > the > > following which I don't know if it should read something else for the > log4j > > logging to be used: > > > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > > > I'm digging and don't know where else to look and am probably not looking > > in the right places. > > > > Any Help is greatly appreciated. I think I am close. > > The trick is that catalina.out isn't managed by any Java-based logger... > catalina.out is where the JVM process's stdout/stderr streams have been > redirected by the startup script -- almost certainly catalina.sh. > > If you read bin/catalina.sh, you'll find some lines that look like this: > > eval "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER > $JAVA_OPTS $CATALINA_OPTS \ > -Djava.endorsed.dirs="\"$JAVA_ENDORSED_DIRS\"" -classpath > "\"$CLASSPATH\"" \ > -Dcatalina.base="\"$CATALINA_BASE\"" \ > -Dcatalina.home="\"$CATALINA_HOME\"" \ > -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \ > org.apache.catalina.startup.Bootstrap "$@" start \ > >> "$CATALINA_OUT" 2>&1 "&" > > (Those are in there a few times, FYI, depending on certain options.) > > The last line in there redirects everything to catalina.out. This makes > it essentially non-rotatable. > > So, what to do? > > Well, have a look at this, which is rather terse: > http://wiki.apache.org/tomcat/FAQ/Logging#Q10 > > Basically, your options are: > > a) Stop logging so much to stdout/stderr (this is the *right* solution, > but if the "vendor" isn't helpful, then there's not much you can do here). > > b) Modify the <context> element in your deployment descriptor to specify > swallowOutput="true". This will redirect System.err and System.out of > the application to a logger that *is* affected by the JULI/Log4j > configuration. This is the easiest solution for an administrator. > > c) Use jsvc to launch Tomcat instead of the startup scripts. jsvc is > capable of re-opening its logs in response to a SIGUSR1 signal similar > to what Apache httpd does. You can use logrotate just as you would do > with httpd except you need to use SIGUSR1 as the signal to send to jsvc > in your "postrotate" scriptlet. > > d) Modify catalina.sh to pipe the output through chronolog, rotatelogs, > etc. instead of redirecting to a file. Then, manage the rotation of the > log file using whatever pipe-based logger you choose to use. This is > fairly easy to do, but upgrading Tomcat means you have to remember to > re-enable the piped-logger, because you'll get a fresh copy of > catalina.sh with the new version of Tomcat. > > e) If you use the venerable logrotate, set it to rotate catalina.out > with the "copytruncate" option. See the logrotate man page for details. > > I'll try to update the FAQ with some of this extra information. > > Hope that helps, > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
