大年夜输出可以看出，/tmp/access_log文件被过程httpd锁定，而httpd过程还一向向这个文件写入日记数据，最后一列的‘deleted’状况解释这个日记文件已经被删除，然则因为过程还在一向向此文件写入数据，是以空间并未释放。

解决问题：

到这里问题就根本排查清跋扈了，解决这一类问题的办法有很多，最简单的办法就是封闭或者重启httpd过程，当然重启操作体系也可以。不过这些并不是最好的办法，对待这种过程一向对文件写日记的操作，要释放文件占用的磁盘空间，最好的办法是在线清空这个文件，具体可以经由过程如下敕令完成:

# echo “ ” >/tmp/access_log 

# find /var/spool/clientmqueue –type f –print –exec rm –f {} \; 

经由过程这种办法，磁盘空间不只可以立时释放，也可以保障进城持续向文件写入日记，这种办法经常用于在线清理apache /tomcat/nginx等web办事产生的日记文件。

问题5：“too many open files”缺点与解决办法

问题现象：这是一个基于java的web应用体系，在后台添加数据时提示无法添加，于是上岸办事器查看tomcat日记，发明如下异常信息，java.io.IOException: Too many open files

经由过程这个报错信息，根本断定是体系可以用的文件描述符不敷了，因为tomcat办事室体系www用户启动的，于是以www用户上岸体系，经由过程ulimit –n 敕令查看体系可以打开最大年夜文件描述符的数量，输出如下：

$ ulimit –n 
 
65535 

可以看到这台办事器设置的最大年夜可以打开的文件描述符已经是65535了，这么大年夜的值应当够用了，然则为什么提示如许的缺点呢

解决思路，这个案例涉及ulimit敕令的应用

一般来说不会出现删除文件后空间不释放的情况，然则也存在例外，好交手件过程锁定，或者有过程一向在向这个文件写数据，要懂得这个问题，就须要知道linux下文件的存储机制和存储构造。

如不雅用户应用的是bash，那么可以在用户目次的情况变量文件.bashrc或者.bash_profile中参加“ulimit –u128”来限制用户最多可以应用128个过程

2、 在应用法度榜样的启动脚本中参加

如不雅应用法度榜样是tomcat，那么可以再tomcat的启动脚本startup.sh中参加‘ulimit –n 65535’来限制用户最多可以应用65535个文件描述符

3、 直接在shell敕令终端履行ulimit敕令

在懂得ulimit常识后，接着膳绫擎的案例，既然ulimit设置没有问题，那么必定是设置没有生效导致的，接下来检查下启动tomcat的www用户情况变量是否添加ulimit限制，检查后发明，www用户并无ulimit限制。于是持续检查tomcat启动脚本startup.sh文件是否添加了ulimit限制，检查后发明也没有添加。最后考略是否将限制加到了limits.conf文件中，于是检查limits.conf文件，操作如下

# cat /etc/security/limits.conf |grep www 
 
www soft nofile 65535 
 
www hard nofile 65535 

大年夜输出可知，ulimit限制加在limits.conf文件中，既然限制已经添加了，设备也没有什么错，为何还会报错，经由思虑，断定只有一种可能，那就是tomcat的启动时光早于ulimit资本限制的添加时光，于是起首查看下tomcat启动时光，操作如下

# uptime 
 
Up 283 days 
 
# pgrep –f tomcat 
 
4667 
 
# ps –eo pid,lstart,etime|grep 4667 
 
4667 Sat Jul 6 09;33:39 2013 77-05:26:02 

大年夜输出可以看出，这台办事器已经有283没有重启了，而tomcat是在2013年7月6日9点启动的，启动了将近77天，接着持续看看limits.conf文件的修改时光，

# stat /etc/security/limits.conf 

经由过程stat敕令清除的看到，limits.conf文件最后的修改时光是2013年7月12，晚于tomcat启动时光，清跋扈问题后，解决问题的办法很简单，重启一下tomcat就可以了。

问题6：(Apache常见缺点故障案例)”no space left>