☰

进程如何拥有比硬限制设置的更高的打开文件描述符限制？

tag-icon • tag-icon solaris file-descriptors open-files ulimit
进程如何拥有比硬限制设置的更高的打开文件描述符限制？

我在用索拉里斯 11据我了解，非特权用户可以增加或减少最大打开文件描述符的软限制，同时保持在硬限制范围内。非特权用户也可以减少硬限制，但一旦减少就无法增加硬限制。

我正在经历以下场景。我有一个非特权用户，其软限制和硬限制使用命令设置如下ulimit。

软限制：10000

硬限制：10000

-bash-4.4$ ulimit -n
10000
-bash-4.4$ ulimit -Hn
10000
-bash-4.4$ ulimit -Sn
10000

这意味着用户不应该能够启动最大打开文件描述符限制高于 10000 的任何进程。但是我无法解释某些以同一用户身份运行且打开文件描述符限制更高的进程。我有几个这样的进程正在运行。

-bash-4.4$ plimit 12553
12553:  
   resource              current         maximum
  time(seconds)         unlimited       unlimited
  file(blocks)          unlimited       unlimited
  data(kbytes)          unlimited       unlimited
  stack(kbytes)         8192            unlimited
  coredump(blocks)      unlimited       unlimited
  nofiles(descriptors)  65536           65536
  vmemory(kbytes)       unlimited       unlimited

它是一个java进程并且运行在索拉里斯区。父进程是zsched.提供的所有信息均来自该区域内。处理命令也如下所示。

java -d64 -DAppName=java_app -server -Xms2048m -Xmx6144m -Xmn2040m -

我没有太多关于该流程本身及其启动方式的信息。我是否缺少任何特定的场景，可以允许该非特权用户使用更高的打开文件描述符限制？

我的假设：

这些信息可能会有所帮助。在有问题的机器上，/etc/profile使用以下命令在文件中设置限制：

ulimit -n 10000

这意味着，每次用户登录时都会调用该文件并应用限制。我的假设是，此类进程可能不会使用正常的交互式登录甚至非登录 shell 启动。在交互式登录和交互式非登录 shell 中都会调用/etc/profile（根据我的观察）；因此从该 shell 启动的进程不应具有更高的文件描述符限制。

这可能是由于像脚本或 cron 这样的非交互式 shell 不需要调用/etc/profile，因此可能使用一些其他默认限制。但从这些流程来看，这种情况似乎不太可能发生。还有其他的可能性吗？

尽管我们支持 Solaris，但社区并没有多大帮助；所以我们依靠这些论坛来寻求帮助。

答案1

不确定我完全遵循你的要求。

可能性是 SA 将 ulimit 条目添加到 COTS 产品（通常是数据库）或自定义应用程序的 /etc/profile 中。

您通过 plimit 看到不同值的原因可能是用户/应用程序可能设置了不同的值，或者它可能被另一个资源控制机制拾取。即：/etc/project

相关内容