Baldinof / caddy-supervisor

Run and supervise background processes from Caddy
MIT License
80 stars 7 forks source link

SIGINT not properly passed down #11

Closed freekdegreef closed 1 month ago

freekdegreef commented 1 month ago

I know there's not much activity in this project, but here goes nothing: We use Caddy Supervisor to run a Laravel artisan command within Caddy (php artisan queue: work --queue=default --max-jobs=200) inside a Frankenphp docker container. The issue we have is that when the container exits (locally or on GCP Cloud Run), the SIGINT signal seems to not be properly passed down to the PHP process, which results in an error and possibly the cutting of a job that's being run. Here's the full output of what we're seeing:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
2024/09/27 12:37:58.563 INFO    using config from file  {"file": "/etc/caddy/Caddyfile"}
2024/09/27 12:37:58.578 INFO    adapted config to JSON  {"adapter": "caddyfile"}
2024/09/27 12:37:58.578 WARN    Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies    {"adapter": "caddyfile", "file": "/etc/caddy/Caddyfile", "line": 2}
2024/09/27 12:37:58.589 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2024/09/27 12:37:58.592 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000406680"}
2024/09/27 12:37:58.600 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2024/09/27 12:37:58.601 INFO    FrankenPHP started šŸ˜   {"php_version": "8.2.23", "num_threads": 10}
2024/09/27 12:37:58.603 INFO    autosaved config (load with --resume flag)      {"file": "/config/caddy/autosave.json"}
2024/09/27 12:37:58.603 INFO    serving initial configuration
2024/09/27 12:37:58.624 INFO    tls     cleaning storage unit   {"storage": "FileStorage:/data/caddy"}
2024/09/27 12:37:58.626 INFO    supervisor      process started {"command": ["php", "artisan", "queue:work", "--queue=default", "--max-time=3600"], "replica": 0, "pid": 27}
2024/09/27 12:37:58.632 INFO    tls     finished cleaning storage units
^C2024/09/27 12:38:01.963       INFO    shutting down   {"signal": "SIGINT"}
2024/09/27 12:38:01.964 WARN    exiting; byeee!! šŸ‘‹     {"signal": "SIGINT"}
2024/09/27 12:38:01.965 INFO    FrankenPHP stopped šŸ˜
2024/09/27 12:38:01.967 INFO    http    servers shutting down with eternal grace period
2024/09/27 12:38:01.987 ERROR   supervisor      process exited with error       {"command": ["php", "artisan", "queue:work", "--queue=default", "--max-time=3600"], "replica": 0, "error": "signal: interrupt", "duration": 3.378900933}
2024/09/27 12:38:01.988 INFO    admin   stopped previous server {"address": "localhost:2019"}
2024/09/27 12:38:01.989 INFO    shutdown complete       {"signal": "SIGINT", "exit_code": 0}

So the error we see is output from the !failedAtStart condition in supervisor.go, and it feels like we never actually get to the Stop() function that would handle this signal. Does anyone have any idea what is going on here?

freekdegreef commented 1 month ago

We could not solve this issue, and the project looks to be dead, so we went with regular supervisor instead.