PHP_TIMEOUT doesn't update max_execution_time in php.ini

[jaydio]

Summary

$PHP_TIMEOUT variable only sets php_admin_value[max_execution_time] in /etc/phpXX/php-fpm.conf but does not update max_execution_time in php.ini.

Steps to reproduce

Set PHP_TIMEOUT=1200 environment variable for app container in docker compose file and fire up a new stack.

Spawn a shell in that app container and verify:

/ # grep exec /etc/php82/php-fpm.conf 
php_admin_value[max_execution_time] = 1200

/ # grep exec /etc/php*/php.ini
max_execution_time = 30

In the case of the tiredofit/freescout image, the scheduler and queue processes are executed using the php-cli binary, which relies on the settings specified in /etc/phpXX/php.ini. This works alright for smaller installations, but causes problems when using dozens of mailboxes. In that case, the fetch mail process gets interrupted with signal 15 once the timeout is reached.

# laravel.log
[...]
The process has been signaled with signal "15"

What is the expected correct behavior?

• Image version / tag: All PHP-FPM images

Possible fixes

Setting PHP_MEMORY_LIMIT=3G does update both, php-fpm.conf and php.ini:

/ # grep -E 'memory_limit' /etc/php82/php-fpm.conf 
php_admin_value[memory_limit] = 3G

/ # grep 'memory_limit' /etc/php82/php.ini 
memory_limit = 3G

Proposing to update the PHP-FPM scripts to set max_execution_time in php.ini based on $PHP_TIMEOUT.

Temporary Workaround

As specified in issue #50 .

env variables of the app container in the compose file now contains this:

"CONTAINER_POST_INIT_COMMAND=sed -i 's|max_execution_time =.*|max_execution_time = 360|g' /etc/php*/php.ini"

which "works" ...

[tiredofit]

This should absolutely be resolved. Let me patch this up.

[tiredofit]

tiredofit/nginx-php-fpm:<variant>-7.6.15 contains the fix for this, this was definitely an issue. Also, since you have found this issue affecting freescout I have just made tiredofit/freescout:1.17.27 as a new build that will take in these new changes.

Interesting, one of my clients has also been suffering for a few months with freescout (100 mailboxes, couple hundred users) with Signal 15 issues that would randomly appear, and techs have been unable to diagnose. If this resolves I'm sure they will be very pleased to hear that this no longer needs their attention.

[jaydio]

tiredofit/nginx-php-fpm:<variant>-7.6.15 contains the fix for this, this was definitely an issue. Also, since you have found this issue affecting freescout I have just made tiredofit/freescout:1.17.27 as a new build that will take in these new changes.

Interesting, one of my clients has also been suffering for a few months with freescout (100 mailboxes, couple hundred users) with Signal 15 issues that would randomly appear, and techs have been unable to diagnose. If this resolves I'm sure they will be very pleased to hear that this no longer needs their attention.

While this did fix the signal 15 issue for most installations, it didn't for one with 50+ mailboxes (mixed google and self-hosted IMAP servers).

However, what seems to have fixed the issue in the end, was installing a separate cron job for the fetch-emails job as such:

[root@dockerhost compose-project]# cat assets/cron_fetch 
*/5 * * * * sudo -u nginx TZ=Asia/Manila php /www/html/artisan freescout:fetch-emails >> /dev/null 2>&1

Yes, the timezone is hard coded, could use the respective variable for it.

Then map the asset in the docker compose file:

  freescout-app:
    volumes:
      - ./assets/cron_fetch:/assets/cron/fetch

Bring down the stack and bring it back up using docker compose down and docker compose up -d.

This has fixed the issue and for the past 12 hours, the queue:work and freescout:fetch-emails jobs have been running smoothly, happily processing thousands of mails, sending out customer responses and user notifications etc.

I also set APP_FETCH_SCHEDULE=5 in the config (manage -> settings -> mail settings -> fetch interval).

It's worth noting that multiple fetch-emails jobs can run in parallel. If the initial job runs for more than 5 minutes, you'll get multiple processes. While this is already shady enough, but probably a good idea to build a wrapper script to ensure only one process runs at a time.

Not much love for laravel from my end. A lot of laravel based applications seem to be suffering from this.

[jaydio]

Correction, since deploying the additional cron job, we've had two signal 15 errors in the laravel log, but no notifications for email fetching problems were sent out:

Either way, the root cause is somewhere in laravel and needs to be addressed there.

[tiredofit]

Darn. Yes this sounds like exactly what my client is seeing after moving to somewhere around freescout 1.8.71. We'll have to get a report into the developers on this one as unfortunately there doesn't seem to be a pattern to reproduce.

EDIT: Also, if you'd like I can have a member of my team reach out to compare notes and double up to get an issue out onto the freescout repository.