我们从应用程序团队获得了对moar文件句柄的持久请求！所以我试图找到一种方法来解决这个问题.所以我做了一个傀儡事实：

Facter.add('app2_nofile') do
  confine :kernel => 'Linux'
  setcode do
    kernel_nofile = `/bin/cat /proc/sys/fs/file-max`.chomp
    app2_limit = (kernel_nofile.to_i * 0.85).round
    app2_limit
  end
end

它在锡上说的是什么.它采用/ proc / sys / fs / file-max中定义的内核值,占85％,系统使用率为15％.在另一个puppet资源中使用这个:: app2_nofile事实设置一个软硬的nofile ulimit,以便/etc/security/limits.conf更新,并且tada！简单！如果他们想要更多的文件句柄,他们必须更聪明地编写应用程序.

除外,它没有用.尝试使用具有该nofile ulimit的用户打开用户会话(su app2_user – )时,我们收到错误消息：

Could not open session

这很糟糕.

显然,有一个独立于简单ulimits的上限.或者也许我正在理解他们从根本上如何运作. nofile限制如何相互影响,以及什么会导致会话无法创建？

进一步的测试表明,上限可能是静态边界,或者比简单的百分比更复杂.文件最大值为797,567的小型RAM系统可以将此ulimit设置得非常高,我将无法再现.在一个拥有1,619,938的大型系统上,我可以将ulimit设置为大约63％,然后才能“无法打开会话”.我现在没有任何更大的东西来测试,看看这个百分比是否随着更大的RAM移动.

我收到了audit.log条目：

type=USER_START msg=audit(1416420909.479:511331): user pid=5022 uid=0 auid=1194876420 ses=44826 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open 
acct="app2" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=Failed'

op是PAM操作.