dunglas
commented
2 months ago Would you happen to know if the process crashes? If yes, could you try to gather a stack trace (https://frankenphp.dev/docs/contributing/#debugging-segmentation-faults-with-static-builds)? If that's not the case, could you provide us with a minimal reproducer?
As a workaround, you can likely use a standard PHP CLI build instead of FrankenPHP's built-in runner for your queue worker (and still use FrankenPHP to serve HTTP requests).
alexandrecruz
masterbater
sneycampos
withinboredom
What happened?
We are considering moving our Laravel 10 apps running in k8s to Frankenphp. We run separate pods for the app, a queue worker, and a scheduler. I managed to get the app working without issues, but the queue worker is giving me issues. Using the
frankenphp:2.8.4-alpineimage and this command the queue works:frankenphp php-cli artisan queue:work --queue=default --max-jobs=200. We use the Spatie Laravel health package for a health endpoint, in the case of the queue worker container we run this as a command since there's no webserver running using this command:frankenphp php-cli artisan health:check --fail-command-on-failing-check. This is done by a k8s livenessProbe. However, when I run the queue worker in this way, the health checks work a couple of times, but as soon as the queue has any work to do, they start timing out and crash the pod. I've tried adjusting RAM and the health probe thresholds, and this improves things a little, but it's nowhere near stable enough.When I do the exact same thing using the same base images the Frankenphp image was built from (php:8.2-alpine) and using PHP directly (
php artisan queue:work --queue=default --max-jobs=200) this works without issue. Maybe I'm approaching this the wrong way or maybe it's an actual bug. Curious if anyone here as any insight on this.Build Type
Docker (Alpine)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
Relevant log output
No response