我有一台基于 64bit Fedora 24
的简化单用户操作系统的机器:我写了一个简单的脚本/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
如果我通过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上我也做了测试,结果是一样的......
答案 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
但我不知道这个解决方案的确切后果,所以我不推荐它。