我正在进行的一个项目是将某些傀儡应用的ulimit设置从“听起来正确的”移到了基于环境的dynamic分配。 这是针对单一应用程序环境的，所以我最担心的是防止应用程序资源匮乏，同时保持内核和实用程序空间足够多的句柄，而不是做他们应该做的事情。
我们从应用程序团队持续请求moar文件句柄！ 所以我试图find一个方法来处理这个问题。 所以我做了一个傀儡事实：
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 - ）时，我们得到错误信息：
无法打开会话
哪个不好。
显然，有一个独立于简单限制的上限。 或者，也许我正在理解他们如何从根本上工作。 nofile限制如何相互影响，会导致会话无法创build？
进一步的testing表明，上限可能是一个静态的边界，或者比简单的百分比更复杂。 一个最大文件大小为797,567的小RAM系统可以将这个ulimit设置得非常高，我就不会再生产了。 在一个更大的系统上，我可以将这个ulimit设置为大约63％，然后才能“打开会话”。 现在我没有更大的内存来testing这个比例是否随着更大的内存而变化。
我得到一个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'
操作是PAM操作。
这似乎是PAM的一个function：
https://bugzilla.redhat.com/show_bug.cgi?id=485955
虽然不是确定性的，但是来源将是这个地方，这强烈暗示PAM在某些资源上实施某种上限。 当我在su命令中使用strace来查看它正在尝试执行的操作是否被拒绝的时候，我看到了这一行：
setrlimit（RLIMIT_NOFILE，{rlim_cur = 1049000，rlim_max = 1049000}）= -1 EPERM（不允许操作）
除了PAM失败之外，audit.log中没有任何logging，syslog不显示任何内容，只是这一个失败。
为了达到我的目的，我将这个事实写成静态值或内核最大文件的85％。 我需要做更多的testing来弄清楚这个静态值是什么，但是似乎这种混合方法会更好的支持这个工具。