& Tomcat关闭日志catalina.out
Tomcat关闭日志catalina.out
翻了下收藏夹，顺手整理到这里来。
catalina.out文件会越来越大，对系统的稳定造成了一定的影响。conf/logging.properties
一般在部署Tomcat后，运行久了，catalina.out文件会越来越大，对系统的稳定造成了一定的影响。
可通过修改conf/logging.properties日志配置文件来屏蔽掉这部分的日志信息。
catalina.org.apache.juli.FileHandler.level = WARNING
catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
catalina.org.apache.juli.FileHandler.prefix = catalina.
将level级别设置成WARNING就可以大量减少日志的输出，当然也可以设置成OFF，直接禁用掉。
一般日志的级别有：
SEVERE (highest value) & WARNING & INFO & CONFIG & FINE & FINER & FINEST (lowest value)
/blog/752416
Linux下的tomcat产生的日志文件不象windows下的按时间时间和大小来处理，
尽管也生成了日志文件catalina.x.log类型的文件，但是其中的catalina.out文件依然增大；它为啥在增大，为啥在增大，原因我就不探究了。
Tomcat的官方文档，由于是外文，偶还没有看明白di；
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
据说是修改某些配置可以实现，希望高人指点，给个官方的解决方案；
老是增大也不是办法，还是想其他办法搞定它为好：
方法1—分割流
使用cronolog工具切分Tomcat的catalina.out日志文件
cronolog一个对日志切分的小工具，其主页在http://cronolog.org/，我们也可以用它来切分Apache的日志。
具体的方法，您可以去google之，这个方法占网络搜索结果的主流；
方法2—脚本流
事情终究不过是个大文件处理的问题，强大的bash来搞定；
使用cron每天来备份当前的catalina.out，然后清空他的内容；
参考脚本如下：
y=`date &+%Y&`
m=`date &+%m&`
d=`date &+%d&`
cd /PATH /tomcat/logs
cp catalina.out catalina.out.$y$m$d
echo & catalina.out
注意linux系统的cron服务是否启动，是否正常工作，还有脚本的存放路径（原因暂保密）
方法3—猥琐流
打开bin目录下的catalina.sh文件，终究不过是个bash文件，
查找一下，catalina.out总共出现三次；
touch &$CATALINA_BASE&/logs/catalina.out
if [ &$1& = &-security& ] ; then
echo &Using Security Manager&
&$_RUNJAVA& $JAVA_OPTS &$LOGGING_CONFIG& $CATALINA_OPTS \
-Djava.endorsed.dirs=&$JAVA_ENDORSED_DIRS& -classpath &$CLASSPATH& \
-Djava.security.manager \
?-Djava.security.policy==&$CATALINA_BASE&/conf/catalina.policy \
-Dcatalina.base=&$CATALINA_BASE& \
-Dcatalina.home=&$CATALINA_HOME& \
-Djava.io.tmpdir=&$CATALINA_TMPDIR& \
org.apache.catalina.startup.Bootstrap &$@& start \
&& &$CATALINA_BASE&/logs/catalina.out 2&&1 &
if [ ! -z &$CATALINA_PID& ]; then
echo $! & $CATALINA_PID
&$_RUNJAVA& $JAVA_OPTS &$LOGGING_CONFIG& $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_BASE&/logs/catalina.out 2&&1 &
个人觉得也就是这里是写catalina.out文件的；让他写到一个其他的空设备如何？
修改前注意原文件的catalina.sh的备份哟~！！
修改以上代码中的
&& “$CATALINA_BASE”/logs/catalina.out 2&&1 &
&& /dev/null 2&&1 &
保存，然后启动tomcat，目前这个 catalina.out一直是空的了。
这个方法是偶自己想到的，个人认为比较勇敢，目前还没有在生产环境测试过。虚拟机测试是通过的。
方法4—人流
这个方法其实就是linux系统管理员手工去删除，人工操作，简称“人流”；
删除之前最好停止tomcat的服务；
本文的评论功能被关闭了.&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！Java基础（43）
System.exit() 的本质是通知 JVM 关闭。
一般来说，有两种禁用 System.exit() 的办法：
安全管理器
本质都是JRE 提供的本地实现，在执行之前进行权限判断。
因为System.exit() 是一种很暴力的手段，如果在 Client 模式下自己写个小程序无所谓,但是在 Server 上多个程序、或者多线程时就会有很大的麻烦。
1.先来看看静态方法 System.exit() 的源码:
// System.exit()
public static void exit(int status) {
Runtime.getRuntime().exit(status);
应该说很简单, 只是简单地调用运行时的 exit 方法.
2.然后我们看运行时的实例方法 exit:
// Runtime.exit()
public void exit(int status) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkExit(status);
Shutdown.exit(status);
如果有安全管理器，那么就让安全管理器执行 checkExit退出权限检查。
如果检查不通过，安全管理器就会抛出异常(这就是约定！)。
然后当前线程就会往外一路抛异常，如果不捕获，那么该线程就会退出。
此时如果没有其他的前台线程正在运行，那么JVM也会跟着退出。
3.Shutdown 是 java.lang 包下面的一个类。
访问权限是 default, 所以我们在API中是不能调用的。
// Shutdown.exit()
static void exit(int status) {
boolean runMoreFinalizers =
synchronized (lock) {
if (status != 0) runFinalizersOnExit =
switch (state) {
case RUNNING:
/* Initiate shutdown */
state = HOOKS;
case HOOKS:
/* Stall and halt */
case FINALIZERS:
if (status != 0) {
/* Halt immediately on nonzero status */
halt(status);
/* Compatibility with old behavior:
* Run more finalizers and then halt
runMoreFinalizers = runFinalizersOnE
if (runMoreFinalizers) {
runAllFinalizers();
halt(status);
synchronized (Shutdown.class) {
/* Synchronize on the class object, causing any other thread
* that attempts to initiate shutdown to stall indefinitely
sequence();
halt(status);
其中有一些同步方法进行锁定。 退出逻辑是调用了 halt 方法。
// Shutdown.halt()
static void halt(int status) {
synchronized (haltLock) {
halt0(status);
static native void halt0(int status);
然后就是调用 native 的 halt0() 方法让 JVM “自杀“了。
使用安全管理器的实现代码如下所示:
1.定义异常类, 继承自 SecurityException
ExitException.java
public class ExitException extends SecurityException {
private static final long serialVersionUID = 1L;
public ExitException(int status) {
super("忽略 Exit方法调用!");
this.status =
2.定义安全管理器类, 继承自 SecurityManager
NoExitSecurityManager.java
import java.security.P
public class NoExitSecurityManager extends SecurityManager {
public void checkPermission(Permission perm) {
// allow anything.
public void checkPermission(Permission perm, Object context) {
// allow anything.
public void checkExit(int status) {
super.checkExit(status);
throw new ExitException(status);
其中直接拒绝系统退出。
3.增加一个辅助和测试类，实际使用时你也可以自己进行控制。
NoExitHelper.java
public class NoExitHelper {
* 设置不允许调用 System.exit(status)
* @throws Exception
public static void setNoExit() throws Exception {
System.setSecurityManager(new NoExitSecurityManager());
public static void main(String[] args) throws Exception {
setNoExit();
testNoExit();
testExit();
testNoExit();
public static void testNoExit() throws Exception {
System.out.println("Printing works");
public static void testExit() throws Exception {
System.exit(42);
} catch (ExitException e) {
System.out.println("退出的状态码为: " + e.status);
在其中，使用了一个 main 方法来做简单的测试。 控制台输出结果如下:
Printing works
退出的状态码为: 42
Printing works
原来的问题如下:
I’ve got a few methods that should call System.exit() on certain inputs. Unfortunately, testing these cases causes JUnit to terminate! Putting the method calls in a new Thread doesn’t seem to help, since System.exit() terminates the JVM, not just the current thread. Are there any common patterns for dealing with this? For example, can I subsitute a stub for System.exit()?
有一些方法需要测试, 但是在某些特定的输入时就会调用 System.exit()。这就杯具了,这时候 JUnit 测试也跟着退出了! 用一个新线程来调用这种方法也没什么用, 因为 System.exit() 会停止JVM , 而不是退出当前线程。有什么通用的模式来处理这种情况吗? 例如,我能替换掉 System.exit() 方法吗?
Instead of terminating with System.exit(whateverValue), why not throw an unchecked exception? In normal use it will drift all the way out to the JVM’s last-ditch catcher and shut your script down (unless you decide to catch it somewhere along the way, which might be useful someday).
In the JUnit scenario it will be caught by the JUnit framework, which will report that such-and-such test failed and move smoothly along to the next.
在程序中调用 System.exit(whateverValue) 是一种很不好的编程习惯, 这种情况为什么不抛出一个未检测的异常(unchecked exception)呢? 如果程序中不进行捕获(catch), 抛出的异常会一路漂移到 JVM , 然后就会退出程序(只有主线程的话)。
在 JUnit 的测试场景中异常会被 JUnit 框架捕获, 然后就会报告说某某某测试执行失败,然后就继续下一个单元测试了。
当然,给出的解决方案就是前面的那段代码. 你还可以阅读下面的参考文章，查找其他的解决方案。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1376240次
积分：13291
积分：13291
排名：第541名
原创：87篇
译文：136篇
评论：409条
(5)(1)(4)(2)(3)(6)(4)(5)(1)(2)(4)(1)(7)(5)(5)(11)(8)(12)(5)(5)(8)(12)(10)(3)(17)(24)(2)(5)(22)(3)(5)(3)(2)(3)(3)(3)(3)java web 关闭tomcat异常？求救！
[问题点数：50分，结帖人xiang_pao]
java web 关闭tomcat异常？求救！
[问题点数：50分，结帖人xiang_pao]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。}