服务器与Jupyter终端ulimit -n输出不一致问题咨询

核心原因就是Jupyter终端的Bash进程是Jupyter主进程的子进程，它会继承Jupyter进程的文件描述符限制，而非登录Shell的限制。

具体细节 #

• 登录Shell的限制来源：直接登录服务器打开的Shell（如SSH登录后的bash）会读取系统登录级配置（比如/etc/security/limits.conf、/etc/profile、~/.bash_profile），这些配置将文件描述符上限（nofile）设为1048576，所以执行ulimit -n会得到这个值。
• Jupyter进程的限制：Jupyter服务通常通过系统服务（如systemd）或后台脚本启动，这类启动方式不会加载登录Shell的配置文件，其文件描述符上限默认是系统默认值（比如4096），除非启动时显式设置更高限制。
• 子进程继承规则：Jupyter启动终端Bash时，子进程会完全继承父进程（Jupyter）的资源限制，包括文件描述符上限，因此Jupyter终端内ulimit -n结果为4096。
• conda环境不影响的原因：conda仅管理Python包、环境变量等，不会修改系统级资源限制，所以激活conda后ulimit -n仍继承当前Shell的限制。

解决方法 #

如果要让Jupyter终端的文件描述符上限与登录Shell一致，可通过以下方式修改Jupyter启动配置：

1. 通过启动脚本设置：在启动Jupyter的脚本中先设置限制，再启动服务：

   ulimit -n 1048576
   jupyter notebook # 或 jupyter lab
   

2. 通过systemd服务配置：若用systemd管理Jupyter，在对应的service文件中添加：

   [Service]
   LimitNOFILE=1048576
   

   保存后重启Jupyter服务，新打开的终端就会继承更高的限制。

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