一次修改limits.conf 引发的血案

起因:
在重启nginx 过程中，发现有报 open file 限制的警告，于是没考虑太多，直接去修改/etc/security/limits.conf

修改前

*                soft    nofile          65536
*                hard    nofile          65536

修改后

*                soft    nofile          6553600
*                hard    nofile          6553600

保存退出，发现无论是复制窗口还是重新登录都会失败，因为是使用的普通账号，在执行sudo 和su 的时候也会报错如下

sudo: pam_open_session: Permission denied
sudo: policy plugin failed session initialization

原因:

/etc/security/ulimits.conf 文件中nofile 的软硬限制的值不能超过内核参数 /proc/sys/fs/nr_open ，否则就有问题

解决方案

1. 如果已经重启启动，那没有没法了，只能重启，进入单用户模式，然后将limits.conf 修改为正常的
2. 如果只有一个普通账号还登录着，也没有办法了，因为sudo也用不了，只能重启，单用户
3. 如果还有会话使用root 用户登录着，可以直接用root修改回来，或者root把 /proc/sys/fs/nr_open 内核参数调大

关于linux上默认资源限制的一些参考知识

ulimit

ulimit 是用来限制用户在当前会话的资源限制的，若新开一个会话，则用户的会话级资源限制又会回复到默认值。如果要想让用户的资源限制的修改同步到用户的每个限制，有两种做法

• 写入用户家目录的 profile or bashrc 中
• 修改limits.conf

limits.conf

关于limits.conf 中nofile 的修改需要慎重，虽然根据man 手册，可以设置值为 -1，unlimited or infinity indicating no limit，但如果设置为-1，则会出现文章之前出现的问题。我这里还只是将nofile的值修改的太大就出现问题。

内核参数

具体的内核参数的解释可以查看http://man7.org/linux/man-pages/man5/proc.5.html

/proc/sys/fs/file-max

• 操作系统级别的限制，所有进程打开的文件数之和不能超过这个值

/proc/sys/fs/file-nr

• 操作系统级别的参数，查看当前已经打开的文件数以及操作系统允许的最大值

/proc/sys/fs/nr_open

• 进程级别的参数，限制每个进程能打开的最大文件数