Linux CROND资源限制

问题描述

我有一台基于 64位Fedora 24 的小型单用户操作系统的机器：

I have a machine with minified single user OS based on 64bit Fedora 24:

• 供应商：Acer Veriton VN4640G


• CPU：Intel（R）i5-6400T CPU @ 2.20GHz


• RAM：4GB DDR4 2133 MHz
>

• 存储空间：32GB 2,5 ADATA SP600

• Vendor: Acer Veriton VN4640G
• CPU: Intel(R) Core(TM) i5-6400T CPU @ 2.20GHz
• RAM: 4GB DDR4 2133 MHz
• Storage: 32GB 2,5" ADATA SP600

我写了一个简单的脚本 /root/test.sh 在后台运行10000个进程：

I wrote a simple script /root/test.sh which run 10000 processes on background:

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

当我直接从控制台运行此脚本时，它将运行10000睡眠过程和预期的打印数字。

When I run this script directly from console, it runs 10000 sleep processes and print numbers as expected.

# bash test.sh
1
2
...
9999
10000

# ps ax | grep -c [s]leep
10000

Ulimit看起来不错

Ulimit looks well

# cat /tmp/ulimit
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15339
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15339
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

BUT

如果我通过cron（ /etc/cron.d/custom ），例如

0  8  *  *  *    root    bash /root/test.sh

我在 journalc中看到tl -e -o cat 消息，例如：

(root) CMDOUT (494)
(root) CMDOUT (495)
(root) CMDOUT (496)
(root) CMDOUT (/root/test.sh: fork: retry: Resource temporarily unavailable)
(root) CMDOUT (/root/test.sh: fork: retry: Resource temporarily unavailable)
(root) CMDOUT (/root/test.sh: fork: retry: Resource temporarily unavailable)
(root) CMDOUT (/root/test.sh: fork: retry: Resource temporarily unavailable)
(root) CMDOUT (/root/proc.sh: fork: Resource temporarily unavailable)

因此，即使有足够的资源并且用户限制与控制台情况相同，它只能运行约500个进程，然后不能派生任何其他进程。 / p>

So it run only about 500 processes and then cann't fork any other process even if there is still enough resources and user limits are the same as console case.

# free -h
              total        used        free      shared  buff/cache   available
Mem:           3,8G        472M        2,8G         62M        498M        3,0G
Swap:            0B          0B          0B

运行睡眠的次数始终相同。 从cron运行的任务是否有资源限制？

The count of running sleeps is always the same. Is there any recource limit for tasks run from cron?

PS：即使在完整的Fedora 24上，我也进行了测试，结果是相同的。 ..

P.S.: I did the test even on full Fedora 24 and result is the same...

推荐答案

好吧，我在编写此问题时找到了解决方案。

Well, I found a solution during writing this question.

问题的主要指针是我曾经在 journalctl 消息中看到

The main pointer to the problem was that I once saw in journalctl message

kernel: cgroup: fork rejected by pids controller in /system.slice/crond.service

因此，我检查了 cron.service 并找到了一个参数 TasksMax 。

So I checked the cron.service and found a parameter TasksMax.

# systemctl show crond.service
Type=simple
Restart=no
...
TasksMax=512
EnvironmentFile=/etc/sysconfig/crond (ignore_errors=no)
UMask=0022
LimitCPU=18446744073709551615
LimitCPUSoft=18446744073709551615

解决方案

将参数 TasksMax 添加到 /usr/lib/systemd/system/crond.service ，例如：

注意 ：如Mark Plotnick所写，更好的方法是将此服务复制到 / etc / systemd / system / 文件夹，并修改此文件以避免在 /中重写服务升级过程中为usr / 。

Note: As Mark Plotnick wrote, better way is copy this service to /etc/systemd/system/ folder and modify this file to avoid rewriting service in /usr/ during upgrade.

# cat /usr/lib/systemd/system/crond.service
[Unit]
Description=Command Scheduler
After=auditd.service nss-user-lookup.target systemd-user-sessions.service time-sync.target ypbind.service

[Service]
EnvironmentFile=/etc/sysconfig/crond
ExecStart=/usr/sbin/crond -n $CRONDARGS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
TasksMax=100000

[Install]
WantedBy=multi-user.target

然后重新加载systemd守护程序

Then reload systemd daemons

# systemctl daemon-reload

常规解决方案

如果要避免出现此问题您可以使用的任何系统服务hange默认值在 /etc/systemd/system.conf 中，例如：

sed -i 's/#DefaultTasksMax=512/DefaultTasksMax=10000/' /etc/systemd/system.conf

并重新加载systemd守护程序以应用更改

And reload systemd daemons to apply the changes

# systemctl daemon-reload

但是我不知道此解决方案的确切结果，因此我不推荐这样做。

But I don't know the exact consequences of this solution, so I can not recommend it.

这篇关于Linux CROND资源限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！