Freescout cronjob delayed for 10 min after container start

[RisingOpsNinja]

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]

Wow, this is very surprising to me, interesting find. I have other ways of going about this - going to think about this for a bit as this affects quite a few other images of mine as well.

[sayem314]

For me mails fetch is being delayed like 8-10 hours so it's not usable at all now