Linux打开文件夹一直失败,Linux常见系统故障：“Too many open files”错误与解决方法...

原标题：Linux常见系统故障：“Too many open files”错误与解决方法

1、问题现象

这是一个基于的应用系统，在后台添加数据时提示无法添加，于是登录查看Tomcat日志，发现如下异常信息：

java.io.IOException: Too many open files

通过这个报错信息，基本判断是系统可用的文件描述符不够了，由于Tomcat服务是系统www用户启动的，于是以www用户登录系统，通过“ulimit -n”命令查看系统可以打开最大文件描述符的数量，输出如下：

[www@tomcatserver ~]$ ulimit -n

65535

可以看到这台 服务器 设置的最大可打开的文件描述符已经是65535了，这么大的值应该够用了，但是为什么提示这样的错误呢？

2、解决思路

这个案例涉及下ulimit命令的使用，这里简单介绍下ulimit的作用和使用技巧。ulimit主要用来限制对资源的使用情况，它支持各种类型的限制，常用的有：

●内核文件的大小限制。

●数据块的大小限制。

创建文件大小限制。

●可加锁内存大小限制。

●常驻内存集的大小限制。

●打开文件句柄数限制。

●分配堆栈的最大大小限制。

●CPU占用时间限制用户最大可用的数限制。

●所能使用的最大虚拟内存限制。

ulimit使用的基本格式为：

ulimit [options] [limit]

具体的ulimit参数(即options)含义如表1所示。

表1 ulimit参数的含义

在使用ulimit时，有以下几种使用方法。

(1)在用户环境变量中加入

如果用户使用的是bash，那么可以在用户目录的环境变量文件.bashrc或.bash_profile中加入“ulimit -u 128”来限制用户最多可以使用128个 进程 。

(2)在应用程序的启动脚本中加入

如果应用程序是Tomcat，那么可以在Tomcat的启动脚本startup.sh中加入“ulimit -n 65535”来限制用户最多可以使用65535个文件描述符。

(3)直接在shell命令终端执行ulimit命令

这种方法的资源限制仅仅在执行命令的终端生效，在退出或关闭终端后，设置失效，并且这个设置不影响其他 shell 终端。

有时候为了方便起见，也可以将用户资源的限制统一由一个文件来配置，这个文件就是/etc/security/limits.conf，该文件不但能对指定用户的资源进行限制，还能对指定组的资源进行限制。该文件的使用规则如下：

其中：

●domain表示用户或用户组的名字，还可以使用“*”作为通配符，表示任何用户或用户组。

●type表示限制的类型，可以有两个值：soft和hard，分别表示软、硬资源限制。

●item表示需要限定的资源名称，常用的有nofile、cpu、stack等。分别表示最大打开句柄数、占用的CPU时间、最大的堆栈大小。

●value表示限制各种资源的具体数值。

除了limits.conf文件之外，还有一个/etc/security/limits.d目录，可以将资源限制创建一个文件放到这个目录中，系统默认会首先读取这个目录下的所有文件，然后才去读取limits.conf文件。在所有资源限制设置完成后，退出终端，再次登录终端后，ulimit设置即可自动生效。

3、解决问题

在了解ulimit知识后，接着上面的案例，既然ulimit设置没问题，那么一定是设置没有生效导致的。接下来检查下启动Tomcat的www用户环境变量下是否添加了ulimit限制，检查后发现，www用户下并无ulimit资源限制。于是继续检查Tomcat启动脚本startup.sh文件是否添加了ulimit限制，检查后发现也没有添加。最后考虑是否将限制加到了limits.conf文件中，于是检查limits.conf文件，操作如下：

[root@tomcatserver ~]# cat /etc/security/limits.conf|grep www

www soft nofile 65535

www hard nofile 65535

从输出可知，ulimit限制加在了limits.conf文件中，既然限制已经加了，配置也没有错，为何还会报错呢？经过长时间思考，判断只有一种可能，那就是Tomcat的启动时间早于ulimit资源限制的添加时间，于是首先查看下Tomcat的启动时间，操作如下：

[root@tomcatserver ~]# more /etc/issue

CentOS release 6.3 (Final)

Kernel r on an m

[root@tomcatserver ~]# uptime

15:10:19 up 283 days, 5:37, 4 users, load average: 1.20, 1.41, 1.35

[root@tomcatserver ~]# pgrep –f tomcat

4667

[root@tomcatserver ~]# 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天零5个半小时了，接着继续看看limits.conf文件的修改时间，操作如图1所示。

图1 查看limits.conf文件的最后修改时间

通过stat命令可以很清楚地看出，limits.conf文件最后的修改时间是2013-07-12，通过查问相关的 Linux 系统管理人员，基本确认就是在这个时候添加的ulimit资源限制，这样此案例的问题就很明确了。由于ulimit限制的添加时间晚于Tomcat最后一次的启动时间，而在此期间内，Tomcat服务一直未重启过， 操作系统 也一直未重启过，那么ulimit资源限制对于Tomcat来说始终是不生效的，同时，由于此 操作系统 是CentOS 6.3，系统默认的最大可用句柄数是1024，java进程采用的是 Linux 默认的这个值，因此出现“Too many open files”的错误也是合乎情理的。

清楚问题之后，解决问题的方法非常简单，重启Tomcat服务即可。返回搜狐，查看更多

责任编辑：