2. 使用交流
  3. limits.conf修改ulimit后，在命令终端应用中不生效

limits.conf修改ulimit后，在命令终端应用中不生效

虚竹 2018-1-10 2656
问题描述

1.服务器ulimit -n原数值为1024，在limits.conf文件中修改为204800后，重启，使用SSH登录执行ulimit -n命令生效，显示最大打开文件数为204800。

2.但在appnode中，在命令终端软件（软件列表中的命令终端）使用ulimit -n查看仍为1024，并且在软件管家安装的Supervisor中执行的程序会出现报错：too many open files。

3.通过appnode首页-节点管理-节点列表中的命令终端查看，ulimit -n设置数值为204800生效，节点设置中的远程连接同样生效

4.如果卸载受控端，重装后，打开软件列表中的命令终端，ulimit -n生效，Supervisor执行程序不会出现too many open files的错误。

5.执行4之后，重启服务器，又会出现2中的问题，ulimit -n自定义值在软件列表中的命令终端无效，Supervisor中执行的程序持续出现过多连接的报错
收藏的用户（0） X
正在加载信息~
最新回复 (1)
  • 虚竹 2018-1-10
    引用 2楼
    问题分析

    这是 CentOS 6 系统本身的限制，CentOS 7 系统采用了 systemd，无此问题。

    后续版本中，我们会在 AppNode 控制中心/受控端启动时，强制初始化 ulimit -n 值为 102400，以便满足大部分场景的需求。

    1. CentOS 6下的 limits.conf，只会影响用户登录后的 session，如 ssh 登录后，再执行 ulimit -n 查看。

    2. 在 AppNode 本机的命令终端中执行 ulimit -n 时，显示的是 AppNode 服务的 ulimit 值，由于本机命令终端打开时不会产生系统用户登录行为，这里不会产生 session，自然也不会受到 limits.conf 配置的限制，所以是系统的默认值 1024。
    supervisor服务同样存在这个问题。

    3. 这样设置改的是 AppNode 这个进程的 ulimit 值，因此是生效的。

    4. 通过 SSH 卸载受控端并重装，因为 AppNode 是由 SSH session 启动的，因此此后 AppNode 进程的 ulimit 继承了 SSH session 的值，也就是 limits.conf 里的值，因此会生效。

    5. 重启服务器后，AppNode又变为由系统启动，不产生 session，因此 limits.conf 不生效。
返回
发新帖