上下求索

jetty tmp坑爹的陷阱

上一篇 / 下一篇  2013-02-16 15:48:21

今天碰到一个古怪的问题,运行在Jetty服务器下的一个系统,忽然爆出一个“404,页面找不到”的错误,重启系统后问题就解决。之前也碰到一个类似的问题,当时也是重启后搞定,上次事件后,查找了一下原因,没有结果,这事情也就放下了。这次再次出现同样的问题,感觉问题比较严重,必须解决这个隐患了。

出现这个问题后,到服务器上看了一下,发现这个Jetty的进程还在,同样运行的其它几个服务也都正常。分析Jetty和应用日志后,也没有发现异常情况。再次回头看一下,抛出的错误信息:

HTTP ERROR 404

Problem accessing /pages/index.jsp. Reason:

Not Found

这个错误显示是index.jsp这个文件访问不到了。于是到Jetty部署解决war的默认目录/tmp去查看,这时其实已经于事无补了,因为刚才重启过,之前目录中的文件全部会被覆盖。

初步怀疑是war解压出的文件被删除了,问了一下SA有没有cron任务在晚上运行,会不会影响/tmp目录的文件,结果他表示没有。于是继续查看Nginx日志,发现在3点36分钟时,前一个请求返回的是200,后一个就变成404了。这时另外一个同事提醒说,系统默认的tmpwatch任务会清除/tmp目录下的文件。如下:

cat /etc/cron.daily/tmpwatch
#! /bin/sh
flags=-umc
/usr/sbin/tmpwatch “$flags” -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X ‘/tmp/hsperfdata_*’ 10d /tmp
/usr/sbin/tmpwatch “$flags” 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
if [ -d "$d" ]; then
/usr/sbin/tmpwatch “$flags” -f 30d “$d”
fi
done

上面的脚本表示,tmpwatch分根据文件的修改(-m)/创建(-c)时间,清理/tmp下的10天前创建或修改的文件,问题就在这里了。如何解决呢?只要让Jetty解压war文件时,不放在/tmp下就能解决这个问题了。仔细查看Jetty的关于Temporary Directories的描述文档,原来只需要在${jetty.home}目录下创建一个work目录就行了。Jetty的这个Trick害死人,为什么不在Jetty发布包中就默认包含这个目录呢?

教训:使用开源的东西,一定要认真读一下它的文档,对于比较关键的问题,一定要非常熟悉,否则出了问题才来想办法解决,已经晚了。


TAG:

 

评分:0

我来说两句

我的栏目

日历

« 2024-03-05  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 125777
  • 日志数: 65
  • 建立时间: 2009-06-24
  • 更新时间: 2013-11-01

RSS订阅

Open Toolbar