Linux CROND资源限制

时间:2018-03-28 12:47:13

标签: linux bash cron multiprocessing limit

我有一台基于 64bit Fedora 24

的简化单用户操作系统的机器:

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

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

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

当我直接从控制台运行此脚本时,它会运行10000个睡眠进程并按预期打印数字。

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

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

Ulimit看起来很好

# 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

我在journalctl -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个进程,然后即使有足够的资源和用户限制与控制台案例相同,也无法分叉任何其他进程。

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

正在运行的睡眠计数始终相同。 从cron运行的任务是否存在任何资源限制?

P.S。:即使在完整的Fedora 24上我也做了测试,结果是一样的......

1 个答案:

答案 0 :(得分:0)

好吧,我在写这个问题时找到了解决方案。

问题的主要指针是我曾在journalctl消息

中看到的
kernel: cgroup: fork rejected by pids controller in /system.slice/crond.service

所以我检查了cron.service并找到了参数 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/中的服务。

# 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守护进程

# systemctl daemon-reload

一般解决方案

如果您想避免任何systemd服务出现此问题,可以更改/etc/systemd/system.conf中的默认值,例如:

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

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

# systemctl daemon-reload

但我不知道这个解决方案的确切后果,所以我不推荐它。