基于Fedora 24的系统中CROND资源限制问题咨询

我来帮你拆解下问题根源，以及对应的解决办法：

问题本质 #

你在控制台直接运行脚本时，登录Shell会加载用户级的资源配置（比如~/.bashrc、/etc/profile里的ulimit规则），这些配置通常会调高进程数、文件描述符等资源上限，所以能顺利启动10000个sleep进程。但Cron执行任务时，不会加载这些Shell配置，它使用的是系统默认的严格资源限制（比如默认的用户最大进程数可能远低于10000），导致无法创建足够的进程。

具体解决步骤 #

1. 先确认Cron环境的资源限制

先搞清楚Cron下的ulimit具体数值，和控制台环境做对比：

• 创建一个临时Cron任务，输出ulimit信息：

  * * * * * ulimit -a > /tmp/cron_ulimit 2>&1
  

• 等待1分钟后，查看/tmp/cron_ulimit，重点关注max user processes（用户最大进程数）和open files（最大打开文件描述符）两项，你会发现Cron里的数值明显比控制台的/tmp/ulimit低很多。

2. 在脚本中手动调整资源限制

在你的/root/test.sh脚本开头，添加ulimit调整命令，把进程数和文件描述符调高到足够的数值：

# 调整用户最大进程数到12000（预留冗余）
ulimit -u 12000
# 调整最大打开文件描述符到20000（每个进程至少占用几个FD）
ulimit -n 20000

# 原脚本内容
ulimit -a > /tmp/ulimit
i=1
while [ $i -le 10000 ]; do
    echo $i
    sleep 60 &
    disown
    i=$(( $i + 1 ))
done

3. 调整系统级资源限制（若脚本设置不生效）

如果脚本里的ulimit命令报错（提示cannot modify limit: Operation not permitted），说明系统级的硬限制挡住了，需要修改/etc/security/limits.conf：

• 编辑该文件：

  vi /etc/security/limits.conf
  

• 添加以下针对root用户的规则：

  root soft nproc 12000
  root hard nproc 12000
  root soft nofile 20000
  root hard nofile 20000
  

• 重启Cron服务让配置生效：

  systemctl restart crond
  

4. 可选：优化脚本的进程创建效率

虽然不是必须，但启动10000个进程的循环可以优化，用seq配合xargs减少循环开销：

ulimit -u 12000
ulimit -n 20000
ulimit -a > /tmp/ulimit

seq 1 10000 | xargs -I {} bash -c 'echo {}; sleep 60 & disown'

验证方式 #

修改完成后，把脚本加入Cron任务，执行后用ps aux | grep sleep | wc -l查看进程数，应该能达到预期的10000个。

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