I am working with a ubuntu web server, where I have tomcat 8 and running a web application on tomcat. Recently I have faced some problem with cpu uses 100%. When I restart the tomcat server it is running good, but after one day or a few hour again same problem arise ( 100% cpu use) and that problem make my site slow. When I see the process list with htop command then i see so many process like
/opt/java8/jre/bin/java -Djava.util.logging.config.file=/opt/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoader
What can i do now? I want to disable tomcat internal logging fully but cannot do this.
What is the function of juli in tomcat? Is it use for only logging? If so i not need any logging. I don't want to see the above process any more. Please help me.
JULI is Tomcat implementation of java.util.logging API. To turn logging off, in ${catalina.base}/conf/logging.properties configure the root logger like this and make sure that there are no child loggers that override this setting:
.level = OFF
Related
If trace is enabled then what is the impact of that option on the server and I need the solution for preventing applications from deployment security misconfigurations by disabling the trace feature.
Probably you don't need to look at "trace" debugging level in Tomcat (that is named "FINEST" instead), but in web application deployed on Tomcat. Logger in webapp determines what kind of logs are added.
Anyway, if you want to filter your logs because you don't have possibility to configure webapp logs, in "conf" folder there is file "logging.properties" where you can setup in detail how to manage application-specific logs. E.g.
5mywebapp.domain.org.apache.juli.FileHandler.level = FINE
5mywebapp.domain.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5mywebapp.domain.org.apache.juli.FileHandler.prefix = mywebapp.
[...]
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/mywebapp].level = FINE
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/mywebapp].handlers = 5mywebapp.domain.org.apache.juli.FileHandler
let Tomcat add logs for webapp under /mywebapp on a different log file. Clearly, performances will change, depending to the type of logs you want to include.
Further details for Tomcat 7 here: https://tomcat.apache.org/tomcat-7.0-doc/logging.html
UPDATE:
if you refer to the Tomcat Connectors option "allowTrace", then this refers to the possibility for Tomcat to accept TRACE requests. Tomcat 7 disables it by default, and option is Tomcat-dependent, indeed you can work on your web.xml to be sure to stop such requests. Further hints here: How to TEST if TRACE, OPTIONS http methods are disabled in Tomcat 7 and indirect answer here: Tomcat security-constraints TRACE inconsistent and finally here (even if referred to Tomcat 6): Disabling PUT TRACE DELETE request in Apache Tomcat 6.0
i am having trouble with configuring Log4j correctly. I was expecting Log4j to rotate my catalina.out file at midnight when configuring it like the following..
log4j.properties:
log4j.rootLogger=INFO, CATALINA
# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.CATALINA.File=/var/log/tomcat7/catalina.out
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern='.'yyyy-MM-dd-HH-mm'.log'
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern =%d{HH:mm:ss} %5p [%t] - %m%n
After configuring I restarted Tomcat and
everything is written to:
/var/log/tomcat7/catalina.out
To test my configuration i changed the current date time to like 23:59:59:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 00:00 catalina.out
As you can see, it didnt rotate at midnight... (?)
When restarting Tomcat it works perfectly fine:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 13:37 catalina.out
-rw-r--r-- 1 tomcat7 root 2395 4. May 00:00 catalina.out.*CURRENTDATE*.log
Is it even possible to rotate my logfiles without restarting Tomcat?
Thanks in advance,
Marley
There are three solutions for this problem:
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.
configure system cron to run logrotate of tomcat log files
change default logging class from ConsoleAppender to FileAppender.
Benefits of solutions:
very flexible as the slf4j offers many options especially with log4j, that you use anyway.
simple and doesn't require touching tomcat configuration.
simple change of configuration that disables console output
Disadvantages:
require additional libraries, affects all applications that tomcat is hosting, requires replacing default configuration with log4j.
cron+logrotate works only in linux; it might be not as simple in windows with scheduler. Requires extra scripting in windows environment.
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.
Is it even possible to rotate my logfiles without restarting Tomcat?
Yes, if you're willing to work for it.
Your log4j configuration will only end up fighting with the standard shell redirection that bin/catalina.sh uses to redirect stdout to logs/catalina.out. You can't simply use log4j configuration to change how System.out behaves.
If you want to rotate conf/catalina.out you will have to take some alternative measures depending on how to launch Tomcat:
If you use jsvc to launch Tomcat and you are using commons-daemon 1.0.4 or later, then you can send SIGUSR1 to the jsvc process to re-open the log files. That will allow you to move the existing log file to another file (which just changes its name and continues to log to the new filename) and then do 'kill SIGUSR1': the original filename will then be re-opened and new logs messages will go to it.
If you use bin/catalina.sh to launch Tomcat, you can modify it so that it no longer does redirection and instead pipes output to a rolling-logger process like Apache httpd's rotatelogs or chronolog.
I have some 5 application running in my tomcat server. I want to build some kind of tool where I can be able to choose one application from the application list and than be able to view the following things-
1.)Detect low memory
2.)Enable or disable GC and class loading verbose tracing
3.)Detect deadlocks
4.)Control the log level of any loggers in an application
5.)Memory used by that application.
6.)Thread view for that application.
I want to have some kind of open source so that i can modify it and integrate it into my web project so that i can view it directly in a webpage.Is there something already existing.?
have a look at http://visualvm.java.net
Enable JMX for your Tomcat server: Monitoring and Managing Tomcat. Then you can manage it with any JMX console. JConsole is the one bundled in JDK.
How to activate JMX on my JROCKIT JVM for access with jconsole?
(somewhat a follow up question to How to activate JMX on my JVM for access with jconsole?)
The main reason I ask is, because I get strange errors if I try to run jboss (6.0.0.Final) with activated JMX, and jboss doesn't start correctly. So maybe it is a jboss problem.
The easiest way to do this, and at the same time support a variety of potential networking configuration challenges, as well as work with any JVM (most ?) is to install a JMXConnectorServer in the JBoss App Server. Now you're using standard J2SE connectivity.
Older builds of JBoss 6 had this support built in and I'm not sure why jboss removed it but here's how you can recreate it.
Find the jar jboss-as-jbossas-jmx-remoting.jar which has a maven signature of org.jboss.jbossas / jboss-as-jbossas-jmx-remoting. Copy it to the [jboss-home]/server/[your-server]/lib directory.
Create a file like jmx-connector-service.xml as outlined below and drop it into your [jboss-home]/server/[your-server]/deploy directory.
(Sorry, was having trouble formatting XML for stackoverflow).
When the server starts, you will see a log statement like this, pretty early on:
INFO [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://10.213.14.95/jndi/rmi://10.213.14.95:1090/jmxconnector
You can tweak the bindings, the use of a registry, the ports etc, but now you can open JConsole and connect to service:jmx:rmi://10.213.14.95/jndi/rmi://10.213.14.95:1090/jmxconnector.
You can find more information on the service here.
Enviroment: JSF 2.0, RichFaces 3.3.3, Facelets 1.1.15B1, Spring Framework 3.x, WebFlow 2.1, MyBatis 3.0.1, Oracle 10/11 g backend, SLF4j into Log4j. Well thats probably TMI since my issue is only a logging problem but better to be too thorough than not.
Anyways... I just setup SLF4j & log4j so now all of the internal facelets log msgs are being dumped into log4j & I can actually see them. In addition I setup Tomcat to also dump to log4j instead of it's custom version of JULI. Upon doing this everything appeared to be working great.... until i shut down the app.
Midway through the shutdown process my app started barfing up errors left 'n right because (which makes sense) Tomcat is trying to grab a logger instance AFTER spring has already cleaned up the logger bean.
Anyone familiar with this? I imagine it must be a common problem for anyone who has Tomcat using the non-standard logging mechanism. What is the best way around this?
I thought maybe if I just raised the log level then Tomcat wouldn't even try to log msgs because of the level req.s but the problem occurs when tomcat is trying to retrieve a logger instance so that didn't work.
I would move the Logger higher in the food chain.
I personally never configured log4j with spring relying on its own configuration mechanism (and hunting for where the heck it finds the properties file it is using in the process).
If you can you can opt to completely remove log4j from your war and rely on the log4j in the common tomcat library classpath. Then of course you are at the mercy of the tomcat configuration and you cannot access the log from inside your app, but it is always there during the complete lifecycle of your app.