Freescout cronjob delayed for 10 min after container start

Summary

After every container restart I noticed that the mails are fetched once then no longer for exactly 10 minutes. After the 10 minutes the mail are fetched once per minute. But it sometimes happens during operation too.

it turns out that busybox crond is responsible for that because it avoids concurrent processes for the first 10 minutes as also observed here: https://superuser.com/questions/1803513/busybox-crond-avoids-concurrent-processes-for-first-10-minutes

Steps to reproduce

start container
constantly check when the mail was last fetched in the log file /www/logs/freescout/fetch-emails.log e.g. using watch cat /www/logs/freescout/fetch-emails.log

What is the expected correct behavior?

The freescout cronjob should run once a minute.

Relevant logs and/or screenshots

busybox crond logs process already running nine times after the container is started:

/var/log/cron/cron.log:

crond: crond (busybox 1.36.1) started, log level 8 crond: USER root pid 3228 cmd sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: user root: process already running: sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: USER root pid 3350 cmd sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1 crond: USER root pid 3412 cmd sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run >> /dev/null 2>&1

The first start of schedule:run starts queue:work which runs constantly in the background (as intended). This probably causes crond to detect that the cronjob is already running:

ps aux | grep artisan

3228 root 0:00 sudo -u nginx TZ=Etc/GMT php /www/html/artisan schedule:run 3229 nginx 0:21 php /www/html/artisan schedule:run 3238 nginx 0:00 /usr/bin/php82 artisan queue:work --queue=emails,default,15636d7b2bed4a9caabe956570b8a27d --sleep=5 --tries=1 --timeout=1800

Environment

Image version / tag: php8.3-1.17.92

Possible fixes

Explicitly backgrounding the process in crontab using & makes this phenomenon disappear.

remove freescout cronjob from /etc/crontabs/root
create file /etc/crontabs/nginx
add * * * * * TZ=Etc/GMT php /www/html/artisan schedule:run >/dev/null 2>&1 &

tiredofit / docker-freescout