为何ulimit在不同Shell命令执行场景下返回值不一致？

这个问题其实涉及到Shell进程的资源限制继承规则，以及子Shell的独立性，我给你拆解几个核心原因：

1. 子Shell是独立进程，修改不会影响父Shell #

这是最容易被忽略的点：当你用/bin/sh -c ...或者/bin/bash -c ...启动子Shell时，它是一个完全独立的进程，和当前Shell（父进程）是分离的。你在子Shell里执行ulimit -n unlimited，只会修改这个子Shell进程自己的资源限制，不会对父Shell产生任何影响。

举个直观的例子：

• 父Shell执行：ulimit -n 1024 → 父Shell的文件描述符软限制设为1024
• 直接在父Shell执行：ulimit -n unlimited → 父Shell的软限制改成unlimited（如果硬限制允许）
• 但如果执行：/bin/bash -c 'ulimit -n unlimited; ulimit -n' → 这个子Shell里的ulimit会显示unlimited，但父Shell的ulimit还是1024（如果你之后在父Shell输入ulimit -n）

你觉得“不一致”，大概率是误以为子Shell的操作会同步到父Shell，但实际上两者是完全独立的进程，资源限制是进程级别的，不会跨进程传递。

2. 软限制与硬限制的约束 #

ulimit分软限制（soft limit）和硬限制（hard limit）：

• 软限制是当前进程实际生效的限制，你可以随时调低，或者调高到不超过硬限制的范围
• 硬限制是上限，普通用户只能调低，不能调高（root用户不受此限制）

当你在父Shell执行ulimit -n 1024时，默认修改的是软限制，硬限制可能还是系统默认的最大值（比如65535或者unlimited）。但如果父Shell的硬限制被设为1024（比如你执行了ulimit -Hn 1024），那么子Shell会继承这个硬限制，此时子Shell里执行ulimit -n unlimited会失败——因为软限制不能超过硬限制，最终子Shell的ulimit还是1024，这也会导致和父Shell直接修改的结果不一致。

你可以用ulimit -Hn查看硬限制，ulimit -Sn查看软限制，确认两者的数值。

3. 不同Shell的非交互式模式差异 #

很多Linux发行版里/bin/sh其实是dash的软链接（而不是bash），dash和bash在非交互式模式下的行为有细微差别：

• bash在非交互式模式下（比如bash -c ...）默认不会读取~/.bashrc或~/.bash_profile，而dash的非交互式模式也有自己的配置规则
• 如果你的Shell配置文件里有ulimit的设置，子Shell（非交互式）不会加载这些配置，但父Shell（交互式）会加载，这也可能导致两者的初始限制不同

另外，有些系统会对非交互式Shell有额外的资源限制策略，不过这种情况比较少见。

快速验证方法 #

你可以直接在子Shell里完整执行查看命令，确认子Shell内部的限制：

# 父Shell设置软限制为1024
ulimit -n 1024
# 查看子Shell内部执行后的限制
/bin/bash -c 'ulimit -n unlimited && ulimit -n'

如果输出是unlimited，说明子Shell内部的设置是生效的，只是不会影响父Shell；如果输出还是1024，那大概率是硬限制被限制了，你可以检查ulimit -Hn的数值。

内容的提问来源于stack exchange，提问作者benji