Open hedge-freek opened 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).
@hedge-freek can you share the stack trace?
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).
I also encountred an issue with queue https://github.com/dunglas/frankenphp/issues/968, if I want to use standard php cli build where should I put it?
Is it here
/usr/local/bin/php
I uses the php workaround recommended here for solving Composer Scripts Referencing @php
I also encountred an issue with queue #968, if I want to use standard php cli build where should I put it? Is it here
/usr/local/bin/php
Think he means you must try to use an php image to run the CLI and FrankenPHP only for HTTP request, something like webdevops/php
or serversideup/php:8.3-cli
If you are using frankenphp images, then php-cli is already installed.
If you are using frankenphp images, then php-cli is already installed.
What path? Invoking php artisan points to my custom php using the workaround for composer scripts @php
https://asciinema.org/a/Hx9H8yQjN5mCeqedKndrSBZG8
TL;DW: /usr/local/bin/php
They are based on php:8.X-zts
https://asciinema.org/a/Hx9H8yQjN5mCeqedKndrSBZG8
TL;DW:
/usr/local/bin/php
They are based on
php:8.X-zts
Since I use the workaround for php composer as recommended here in https://frankenphp.dev/docs/known-issues/ Does that mean I replaced the standard php cli?
#!/usr/bin/env bash
args=("$@")
index=0
for i in "$@"
do
if [ "$i" == "-d" ]; then
unset 'args[$index]'
unset 'args[$index+1]'
fi
index=$((index+1))
done
/usr/local/bin/frankenphp php-cli ${args[@]}
# Composer Scripts Referencing @php Composer scripts may want to execute a PHP binary for some tasks, e.g. in a Laravel project to run @php artisan package:discover --ansi. This currently fails for two reasons:
Composer does not know how to call the FrankenPHP binary; Composer may add PHP settings using the -d flag in the command, which FrankenPHP does not yet support. As a workaround, we can create a shell script in /usr/local/bin/php which strips the unsupported parameters and then calls FrankenPHP:
https://asciinema.org/a/Hx9H8yQjN5mCeqedKndrSBZG8
TL;DW:
/usr/local/bin/php
They are based on
php:8.X-zts
Thanks I tried removing the workaround and rebuild docker, it did have a standard php cli, but now Im thinking whats the solution for the composer @php
This workaround is only needed when not using the standard PHP CLI. I'll update the docs to make that clearer. You don't need this workaround with Docker images. It is only necessary when you use the static binary and you don't have a local installation of PHP.
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-alpine
image 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