我有一台基于 64 位 Fedora 24 的精简单用户操作系统的机器:
- 供应商:Acer Veriton VN4640G
- CPU:Intel(R) Core(TM) i5-6400T CPU @ 2.20GHz
- 内存: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 个 sleep 进程并按预期打印数字。
# 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
但是
如果我通过 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
运行 sleep 的计数始终相同。 从 cron 运行的任务是否有资源限制?
P.S.:我什至在完整的 Fedora 24 上进行了测试,结果是一样的......
最佳答案
好吧,我在写这个问题的过程中找到了解决方案。
问题的主要指针是我曾经在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
解决方案
在/usr/lib/systemd/system/crond.service
中的服务配置中添加参数TasksMax,例如:
注意:正如 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
但我不知道这个解决方案的确切后果,所以我不能推荐它。
关于Linux CROND 资源限制,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49534976/