sysctl pk ulimit

 

经过检查，并不是没有设定好，而是用户环境的问题没有读取正确的值。

 

测试过程如下：

 

用普通用户ssh登录，执行ulimit -a ，返回值为1024

 

su - 到root，执行ulimit -a，返回值则为65536

 

su - 到spider，执行ulimit -a，返回值为65536

 

这样说明，只在ssh登录之初，ulimit 为1024

 

su - 后就能取到正确的数据

 

不管ulimit -a得到1024或者65536，当时cat /proc/sys/fs/file-max 都是正确的65536，也就是说ulimit得到数据只是数据而已，65536已经应用在系统中，只不过1024时，是没有得到正确的数值。

 

继续测试，在rc.local中写上ulimit -a，在启动后得到的数据也是1024，cat /proc/sys/fs/file-max 得到的也是65536.

 

HY后来说更改sshd_config，将UsePAM no改为UsePAM yes，ssh登录就恢复正常。

但本地登录仍然不能取到正确值。

 

非要研究系统才能明白......

 

继续 -->>

 

今天看了sysctl，用sysctl -n fs.fs-max 不管什么情况都能取到正确的数据。

 

 

继续 -->>

 

发现sysctl.conf和limits.conf都能改file-max，这两个哪个优先级高呢？如下试验

 

试验一：

sysctl.conf中定义的是65536，limits.conf定义的是1024，重启，系统启动后，ulimit -a 是1024，su - 后仍然是1024。sysctl fs.file-max始终是65536。
/proc/sys/fs/file-max 为65536

 

试验二：

为了确保不是内核中打死65536，将两个文件都改成1024，这样重启后ulimit -a和sysctl fs.file-max都为1024。
/proc/sys/fs/file-max 为1024

 

试验三：

将sysctl.conf改成1024，limits.conf改成65536，重启su -后，ulimit -a是65536，sysctl fs.file-max是1024。
/proc/sys/fs/file-max 为1024

上面试验得出结论，/proc/sys/fs/file-max是由sysctl.conf来决定的。

那limits.conf制定的参数