Linux下limit.conf中修改参数不生效浅析总结

在运维过程中，我们可能会碰到Linux下修改limits.conf中的参数不生效的问题，下面结合自己遇到的几个案例，简单总结、浅析一下Linux下修改limits.conf中参数不生效的一些原因。注意，我们的测试环境：CentOS 7.9.2009。可能不同版本下有所差异或不同，请以实际情况为准，这里没有详细的在各个Linux发行版本测试过。我们仅仅在下面测试环境下简单测试了一下。

测试环境：

kerrydb01 CentOS Linux release 7.9.2009 (Core)

案例场景1：

如下所示，这台测试服务器的单个进程能打开的最大文件数为1024，我们想修改一下这个参数的值

[root@kerrydb01 limits.d] ulimit -n
1024

修改参数文件limits.conf， 新增下面配置。

# vi /etc/security/limits.conf

* hard nofile 65536
* soft nofile 65536

如下所示， 验证发现ulimit -n的值始终是1024。

[root@kerrydb01 limits.d]# ulimit -n
1024
[root@kerrydb01 limits.d]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63373
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 63373
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@kerrydb01 limits.d]#

切换到mysql用户下，发现在mysql用户下面，这个配置修改确实生效了。如下所示：

[root@kerrydb01 limits.d]# su - mysql
Last login: Fri Apr 8 14:39:49 CST 2022 on pts/1
[mysql@kerrydb01 ~]$ ulimit -n
65536

但是root用户下面此参数的值依旧是1024，如果重启系统后，这样的配置就会生效。也就是说CentOS下，通配符*是可以生效的。继续测试，修改/etc/security/limits.conf的配置如下：

root hard nofile 65536
root soft nofile 65536

如果不重启的话，它始终不会生效。不清楚为什么root用户一定需要重启才能生效。而非root用户不重启也可以生效。一般来说，生产环境是不方便重启的。

另外，我查了一些文档资料后发现：在Debian/Ubuntu中，通配符不适用于root用户。Because wildcard is not applied to the root user. 。DESCRIPTION 具体解释如下：

The syntax of the lines is as follows:The fields listed above should be filled as follows:

-   a username 

-   a groupname, with @group syntax. This should not be confused with netgroups. 

 -   the wildcard *, for default entry. 

 -    the wildcard %, for maxlogins limit only, can also be used with %group syntax. 

NOTE:group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

也就是说如果在Debian/Ubuntu中，不能用*这样通配符，否则不会生效。如果是root用户应该指定root用户

案例场景2：

如果在20-nproc.conf和limits.conf中都设置了这个参数的话，哪一个会生效呢？当然，有些Linux发行版本的配置文件为90-nproc.conf，有些是20-nproc.conf。具体配置文件的名字，建议从/etc/security/limits.d进去检查、确认。

xxx hard nofile 65536
xxx soft nofile 65536

测试发现，如果两个配置文件都同时配置了的话，它会优先以20-nproc.conf中配置为准。所以有时候你的配置没有生效，可能是20-nproc.conf或90-nproc.conf也配置了这个参数。只是这些配置文件中的参数优先级高于limits.conf的参数。

# cd /etc/security/limits.d
# ls -lrt
total 4
-rw-r--r--. 1 root root 191 Apr 1 2020 20-nproc.conf

案例场景3：

如下所示，当前mysql用户下

$ ulimit -n
1024

查看mysqld进程的文件句柄限制值是10000， 那么以一个为准呢？答案：查看进程的文件句柄限制，以下面命名为准，而不已ulimit -n为准

cat /proc/limits

$ ps -ef | grep -i mysqld
mysql     35274      1  0 Feb09 ?        04:38:51 /data/mysql/bin/mysqld --defaults-file=/data/mysql/my.cnf
mysql     52346  51361  0 17:37 pts/0    00:00:00 grep --color=auto -i mysqld
$ cat /proc/35274/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             63374                63374                processes
Max open files            10000                10000                files
Max locked memory         65536                65536                bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       63374                63374                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

那么为什么配置文件/etc/security/limits.conf中，soft nofile/hard nofile设置为1024，但是mysqld进程能打开的最大文件句柄为5000呢？因为mysqld的systemctl服务的mysqld.service 的参数设置会覆盖limits.conf中的参数配置

# Sets open_files_limit
LimitNOFILE = 10000

案例场景4：

工作中，也遇到过不管你在limit.cnf中怎么折腾，重启系统也好，始终不生效。这时候，你可能需要检查一下/etc/profile配置文件，看看这里面是否有类似这样的设置（其中*为任意数字），如果有的话，需要取消这种配置。

ulimit -n *****

由于/etc/profile环境变量里的参数配置的优先级最高，它会覆盖limits.conf里的参数配置。而且这种设置比较隐蔽，如果不是你设置的，估计还真要折腾一会儿。