关于配置ulimit

[Zhang Cheng]

在QQ群里 @zhsj 问了关于 ulimit 的问题，因为比较长时间没有人回复，可能后面会被冲掉，所以搬过来。

首先，ulimit是 bash-builtin 命令，所以，ulimit只能修改当前bash进程的属性，子进程一般会自动继承父进程的ulimit设置。

ulimit(user limits)，从名字看就是针对用户的设置，所以其实它是一个进程的属性，没有“全局”的概念。从 /proc/$pid/limits 中可以读出一个进程当前的limit设置。

然后，ulimit 一般在哪里配置呢？一般通过pam_limits.so来配置。配置文件在 /etc/security/limits.{conf,d/}。

什么时候会应用pam_limits.so呢？ grep pam_limits.so -R /etc/pam.d/ 可以看到。

在debian默认的情况下，su、sshd、gdm、login、cron等都会应用pam_limits.so。

然而，upstart和sysvinit都不会应用pam_limits.so（不属于上面的任何一种情况）。

* 对于upstart，需要在配置文件(/etc/init/$service.conf)中增加limit配置语句，见http://upstart.ubuntu.com/wiki/Stanzas#limit

* 对于sysvinit，由于其脚本(/etc/init.d/$service)就是一个普通的bash脚本，所以可以直接用ulimit命令来设置，这个设置会被其子进程继承。

* 我没有用过systemd，不清楚systemd如何处理。刚才查看了一下"man systemd.exec"，里面有一系列 "Limit$RESOURCE" 的配置（如LimitCPU、LimitSTACK等），应该就是用来配置这个的。

--

Cheng,

Best Regards

[SJ Zhu]

在rhel 6.5上，对比了几个节点的/etc/security /etc/init /etc/init.t /etc/pam.d
几个文件夹grep limit内容都是一样的，可是其中有一个节点ulimit值却还是不对。。。

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ustc_lug+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[SJ Zhu]

不知道把ulimit -l unlimited这句放在bashrc里会不会有什么后遗症？。。。

[Zhang Cheng]

​​

2014-06-23 17:25 GMT+08:00 SJ Zhu <zsj9...@gmail.com>:

不知道把ulimit -l unlimited这句放在bashrc里会不会有什么后遗症？。。。

在 2014年6月23日 上午11:04，SJ Zhu <zsj9...@gmail.com> 写道： 

> 在rhel 6.5上，对比了几个节点的/etc/security /etc/init /etc/init.t /etc/pam.d
> 几个文件夹grep limit内容都是一样的，可是其中有一个节点ulimit值却还是不对。。。

limit值​有问题的进程是怎么启动的？登陆上去之后手动启动的，还是通过某个init系统（upstart、sysvinit、systemd等）启动的？

​如果不介意设置/etc/security/limits.{conf,d/}的话，那么设置这个最好。如果不方便做这样的设置（例如只想对登陆之后的bash进程以及后续手动启动的进程设置），那么可以放到bashrc里面，这也仅仅会影响你启动的bash进程以及子进程。通过其他方式启动的shell脚本不受影响（bash脚本不会读取bashrc）。如果你配置了前者，那么在bashrc里面写这个就没有意义。

​不知道你有没有理解我前面邮件里的意思，rlimit这个东西是进程的属性，而不是内核的参数，每个进程都会单独设置，如果进程没有自行设置，那么会继承父进程的。

所以这个问题要对症下药，而不是随便搞一下发现work了就不管了。

以前我就吃过这东西的亏。我当时要设置的是max open files(ulimit -n)，web服务（如java写的web server）在并发请求高时，并发打开的“文件”很多（每一个tcp连接对应一个文件），系统默认的是1024，所以需要调max open files。当时改了/etc/security/limits.d/xxx，发现生效了，就没事了。直到后来某一天又发现日志里大量的报Too many open files，找了半天没找出原因，后来才发现原来upstart和sysvinit都不应用pam_limits.so，所以通过upstart/sysvinit启动的服务以及子进程都需要单独配置limit。

--

Cheng,

Best Regards

[Bojie Li]

如 Zhang Cheng 所说，ulimit 不是节点的，而是进程的。首先找到出现 too many open files 的进程的 PID，cat /proc/$pid/limits 看 ulimit 值是否是你想要的。注意 ulimit 有两个值，生效的是 soft limit，可以自己调整到的最大值是 hard limit，有点像 uid 与 euid 的关系，具体可以 man ulimit。

如果 ulimit 值不是你想要的，cat /proc/$pid/status 找到它的父进程（也可以用 pstree -p），看父进程的 ulimit 对不对。如果父进程是 init，一般说明这个进程是系统服务（daemon），这时找找启动这个服务的脚本，在启动服务之前加入 ulimit 命令。注意 ulimit 跟 cd 一样是 bash 内部命修改令，也就是不会启动新进程去修改 ulimit，ulimit 命令修改的是当前 bash 进程的设置（如果改大，需要 root 权限），后续启动的子进程会继承修改后的 ulimit。

另外请关注 /proc/sys/fs/file-nr，如果已打开的文件描述符接近最大限制，就要提高系统内所有进程打开的文件描述符总数限制：/proc/sys/fs/file-max。

SJ Zhu <zsj9...@gmail.com>编写：

>在rhel 6.5上，对比了几个节点的/etc/security /etc/init /etc/init.t /etc/pam.d
>几个文件夹grep limit内容都是一样的，可是其中有一个节点ulimit值却还是不对。。。
>

[Zhang Cheng]

2014-06-23 18:15 GMT+08:00 Bojie Li <boj...@gmail.com>:

如 Zhang Cheng 所说，ulimit 不是节点的，而是进程的。首先找到出现 too many open files 的进程的 PID，cat /proc/$pid/limits 看 ulimit 值是否是你想要的。注意 ulimit 有两个值，生效的是 soft limit，可以自己调整到的最大值是 hard limit，有点像 uid 与 euid 的关系，具体可以 man ulimit。

​@zhsj 原始的问题不是too many open files，是另外一个资源“The maximum size that may be locked into memory”​，对应的ulimit参数是"-l"。我因为只跟max open files打过交道，所以举例时都以max open files为例，反正本质上都是一样的工具。

从@zhsj上一个回复中看，他似乎是在某一台机器的bash shell上通过ulimit -l命令看到的输出不符合预期，但我觉得他要限制的肯定不是这个bash进程，而应该是另外某个服务进程出问题了。

--

Cheng,

Best Regards

[SJ Zhu]

我遇到的问题如张成师兄所说，无法定位到引入ulimit -l为64的设置的配置。
几个节点可以说是理论上一模一样的，但有一个节点却在ulimit -l的值上出现了差异。

(Sent from my mobile device.)

--

[SJ Zhu]

需要检查max mem lock值的进程是intel mpi。
intel mpi在选择通信设备为ofa时，发现启动失败。开启intel mpi debug模式后发现是max mem lock值过小。从文档上看应该至少32M，结果有一个节点却是64K。
mpi是从bash启动的，应该是继承bash的ulimit值

(Sent from my mobile device.)

2014-6-23 下午12:36于 "Zhang Cheng" <steph...@gmail.com>写道：

--