Aerya Un can't fork
ressemble plus fortement a une saturation du CPU ou ddu nombre de fichier que ton utilisateur peut créer. Sachant qu'un processus est un fichier
Avec systemD, le rlimit est de 1024. Donc ça peut rapidement coincer car. rien que pour lancer ton script c'est 3 fichiers.
Je viens de checker s'il y avait une limite côté cron et il y en a bien une.
systemctl status cron.service
Retourne
root@Mul ~ # systemctl status cron.service
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-09-30 18:44:29 CEST; 1 months 17 days ago
Docs: man:cron(8)
Main PID: 1178 (cron)
Tasks: 5 (limit: 4915)
Memory: 1.8G
CGroup: /system.slice/cron.service
├─ 1178 /usr/sbin/cron -f
├─14204 /usr/sbin/CRON -f
├─14209 /bin/sh -c /opt/rudder/bin/rudder agent check -q >> /var/log/rudder/agent-check/check.log 2>&1
├─14212 /bin/sh /opt/rudder/share/commands/agent-check -q
└─14261 sleep 6404
Et le nombre de tasks est limité. Ici le nombre de tasks est de 5 sur 5000 (ça va, j'suis large), mais en l'occurence tu peux avoir une limite plus faible et un nombre de tache plus important
Si ton nombre de tache est proche de la limite, un coup de
systemctl set-property cron.service TasksMax=new_max
pourra régler ton problème 🙂