再谈Linux的ulimit

测试脚本

[[email?protected] ~]# cat /tmp/test_ulimit.py 
import sys

def test_n():
    total=[]
    try:
        for i in range(0,100000):
            total.append(open(‘/tmp/{}-{}‘.format(‘jjkkll‘,i),‘w‘))
    except Exception as err:
        print(i,repr(err))

test_n()

关于/etc/security/limit.conf中开篇既有两句话提示

#This file sets the resource limits for the users logged in via PAM.
#It does not affect resource limits of the system services.

意思就是这里的限制只对经过PAM验证的登陆用户有效，并明确说明对开机自启的系统服务（经chkconfig 或systemd控制的开机启动服务）以及 /etc/init.d/rc.local（经试验亦无效） 中的命令无效。

另外经验证：同时在/etc/security/limit.conf和/etc/profile中设置不同的值，/etc/profile中的值最终生效（说明PAM认证在profile之前）

那如何在开启及启动的服务中突破系统默认的ulimit值呢？

首相尝试了在/etc/profile中添加对应设置，经测试对开机自启的系统服务和 /etc/init.d/rc.local仍然无效（并且验证了系统服务的运行时间要早于/etc/init.d/rc.local）

[[email?protected] ~]# cat /tmp/log-init 
  (1021,"IOError(24,‘Too many open files‘)")
  Sat Nov  3 06:35:19 EDT 2018
[[email?protected] ~]# cat /tmp/log-rc.local 
  (1021,‘Too many open files‘)")
  Sat Nov  3 06:35:25 EDT 2018
[[email?protected] ~]# ulimit -n
  3000 
[[email?protected] ~]#

而且在/etc/profile中假如ulimit配置(以及任何需要root权限运行的命令)，那在以其他用户登陆时，就会报一条“无权限”类错误。是因为 /etc/profile 在系统启动过程中执行的时机：（倒数第一或 第二步）即任何用户登陆前才/先执行/etc/profile，然后再是 ~/.bash_profile（若有的话）

那么到底该如何解决上面的问题呢？

后经查明，/etc/init.d/xxxx 以及/etc/rc.loca中的命令都是centos7之前的产物，centos7之后系统引导及服务管理由sysV改为了systemd，而systemd对于ulimit中指定的各类限制是在xxxx.service文件中设置的，这也是推荐的方式。例如 LimitNOFILE=65536。

但是如果非要在/etc/init.d/xxxx以及/etc/rc.local中突破默认限制的话

1. 对于/etc/rc.local，有如下方法
   在 /usr/lib/systemd/system/rc-local.service 的 [Service] 段下增加相应配置，如 LimitNOFILE=3000
2. 对于/etc/init.d/xxx
   centos7 中还没找到解决方案(其实执着于此也无意义，因为7的服务管理是systemd)
   centos6 中科通过在/etc/init.d/functions中增加一句ulimit -n 65536（以及其他设置）来解决

经过实验看下来，发现了一个特点，一个进程能打开的文件描述符总是比设置的nofile值小3，这是因为还有0，1，2 三个标准输入，输出，错误的存在。