Open jaydio opened 1 year ago
This should absolutely be resolved. Let me patch this up.
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.
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 madetiredofit/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.
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.
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.
Summary
$PHP_TIMEOUT
variable only setsphp_admin_value[max_execution_time]
in/etc/phpXX/php-fpm.conf
but does not updatemax_execution_time
inphp.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:
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.What is the expected correct behavior?
Possible fixes
Setting
PHP_MEMORY_LIMIT=3G
does update both,php-fpm.conf
andphp.ini
:Proposing to update the PHP-FPM scripts to set
max_execution_time
inphp.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:
which "works" ...