mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5
43260cdee3
The context_agent ExApp calls back into the same php-fpm pool it is being proxied from: its UserAuthMiddleware resolves the bearer against /ocs/v2.php/cloud/user while a child is already parked forwarding the MCP request out to the ExApp. Every in-flight MCP request therefore occupies TWO children. Below twice mcp.limits.concurrent_requests the two legs deadlock, and because the ExApp's callback carries no timeout the pool never recovers -- which is why the Context Agent sat unhealthy rather than merely slow. services.nextcloud.performance.php.fpm now sizes the pool explicitly: max_children 16, start_servers 4, min/max spare 4/8. request_terminate_timeout is 900s and must not drop below the proxy's fastcgi_read_timeout; lower kills a child while nginx is still waiting on it, equal means only work nginx has already abandoned gets reclaimed. The readiness path was spending the same scarce workers. /healthz/ready had no location of its own, so it fell through to `location /`, was rewritten to /index.php/healthz/ready and booted a full Nextcloud request on a php-fpm child once per probe interval against a pool of five. It is an exact-match location returning 200 from nginx now, with access_log off, and never reaches PHP. The pool file is rendered through render_replicated_templates.yml so swarm peers receive it too, and mounted from meta/volumes.yml at a path that sorts after zz-docker.conf, which reopens the [www] section last -- mount it earlier and the image's own values win while the deploy looks correct. The context_agent healthcheck moves from a hand-written probe in compose.yml.j2 to the shared container_healthcheck lookup, declared as flavor curl on path heartbeat with start_period 20m. The ExApp installs dependencies on first boot and legitimately outlives a 60s start period, which is the other half of why it reported unhealthy. Not verified: none of this has deployed. max_children 16 is derived from twice concurrent_requests rather than measured against real memory use, and the mount-ordering requirement is read from the image layout rather than confirmed against a merged pool config in a running container -- if it sorts wrong the whole change is inert while appearing correct. request_terminate_timeout 900s also means a genuinely stuck request now holds a child for fifteen minutes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9 lines
360 B
Django/Jinja
9 lines
360 B
Django/Jinja
{% set fpm = lookup('config', application_id, 'services.nextcloud.performance.php.fpm') %}
|
|
[www]
|
|
pm = dynamic
|
|
pm.max_children = {{ fpm.max_children }}
|
|
pm.start_servers = {{ fpm.start_servers }}
|
|
pm.min_spare_servers = {{ fpm.min_spare_servers }}
|
|
pm.max_spare_servers = {{ fpm.max_spare_servers }}
|
|
request_terminate_timeout = {{ fpm.request_terminate_timeout }}
|