macos - 以编程方式在 OS X/MacOS 上设置 maxfile

Question

如果我使用 launchctl 的 limit 命令查看 maxfiles 选项(在我的 OS X El Cap 机器上)

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    256            unlimited

似乎有 256 的软限制和“无限制”的硬限制。我想将软限制更改为类似 2048 的值，并保持硬限制不变。当我查看 limit 的参数时

$ launchctl help limit
Usage: launchctl limit [<limit-name> [<both-limits> | <soft-limit> <hard-limit>]

看来我可以将两个限制设置为同一事物，或为软硬设置一个值。但是，如果我尝试设置无限的硬限制。

$ sudo launchctl limit maxfiles 2048 unlimited

我最终得到了奇怪的值 10240

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    2048           10240          

这是怎么回事？是否可以设置无限值？如果不是，那是 launchctl limit 命令的限制，还是系统级别的限制？如果是后者，unlimited 报告的初始值是多少？或者这个苹果就是苹果？

对于奖励积分——有人知道为什么这个限制一开始就设置得这么低吗？

Answer 1

来自man page for setrlimit() ，launchd 将依赖于实现此功能的底层系统调用:

setrlimit() now returns with errno set to EINVAL in places that historically succeeded. It no longer accepts "rlim_cur = RLIM_INFINITY" for RLIM_NOFILE. Use "rlim_cur = min(OPEN_MAX, rlim_max)".

因此，虽然 getrlimit() 可能(最初)报告硬限制为 RLIM_INFINITY，但实际上是 OPEN_MAX(10240 ) 因为这只是内核实现方式的限制。如果您尝试设置限制，则需要使用后一个值，这会影响从那时起报告的内容。

至于为什么 RLIM_NOFILE 的软限制默认为 256，这是因为对于绝大多数进程来说，这不是一个实际的约束。他们在没有接近这个限制的情况下相处得很好。保持该值“如此之低”意味着每个进程在内存方面的成本较低，并且每个 fork() 将文件描述符复制到新的子进程等中的工作量较少。

知道自己可能会处理更多文件的程序可以使用 setrlimit() 更改自己的限制。