Php-fpm child process crash when installing / updating an app (on raspberry pi 5)

[mathieu-margier]

Issue

I've noticed that each time I try to install and/or update an app from the web interface, I get the "502: Bad gateway" error for any subsequent requests. When looking at the nextcloud's container logs, it stays the child processes are constantly crashing:

May 12 11:22:00 nextcloud_app[1087224]: [12-May-2026 09:22:00] WARNING: [pool www] child 181 exited on signal 11 (SIGSEGV - core dumped) after 56.485757 seconds from start
May 12 11:22:00 nextcloud_app[1087224]: [12-May-2026 09:22:00] NOTICE: [pool www] child 205 started
May 12 11:22:01 nextcloud_app[1087224]: [12-May-2026 09:22:01] WARNING: [pool www] child 178 exited on signal 11 (SIGSEGV - core dumped) after 214.245756 seconds from start
May 12 11:22:01 nextcloud_app[1087224]: [12-May-2026 09:22:01] NOTICE: [pool www] child 206 started
May 12 11:22:02 nextcloud_app[1087224]: [12-May-2026 09:22:02] WARNING: [pool www] child 204 exited on signal 11 (SIGSEGV - core dumped) after 19.482163 seconds from start
May 12 11:22:02 nextcloud_app[1087224]: [12-May-2026 09:22:02] NOTICE: [pool www] child 207 started
May 12 11:22:02 nextcloud_app[1087224]: [12-May-2026 09:22:02] WARNING: [pool www] child 205 exited on signal 11 (SIGSEGV - core dumped) after 2.076329 seconds from start
May 12 11:22:02 nextcloud_app[1087224]: [12-May-2026 09:22:02] NOTICE: [pool www] child 208 started
May 12 11:22:03 nextcloud_app[1087224]: [12-May-2026 09:22:03] WARNING: [pool www] child 206 exited on signal 11 (SIGSEGV - core dumped) after 2.357498 seconds from start
May 12 11:22:03 nextcloud_app[1087224]: [12-May-2026 09:22:03] NOTICE: [pool www] child 209 started
May 12 11:22:32 nextcloud_app[1087224]: [12-May-2026 09:22:32] WARNING: [pool www] child 209 exited on signal 11 (SIGSEGV - core dumped) after 29.095544 seconds from start
May 12 11:22:32 nextcloud_app[1087224]: [12-May-2026 09:22:32] NOTICE: [pool www] child 210 started

If I restart the nextcloud (php) container, the child process no longer crashes, and the bad gateway error is gone. The app is also correctly installed/updated.

Workaround

When looking for similar issues, I found this Github issue.
They say that OPCache's JIT is not recommended for other architectures than x64, and might be causing the issue.

So, to disable OPCache's JIT, I added the following file, and mounted it as a read-only volume at /usr/local/etc/php/conf.d/tweaks-disable-opcache-jit.ini:

opcache.jit=0
opcache.jit_buffer_size=0

It indeed solved my issue.

Maybe the opcache's JIT should be disabled for non-x64 architecture to avoid troubles ?

Setup

Nextcloud server is running on podman, with raspberry pi 5 (aarch64 / arm64) as host system.
Containers are managed using podman quadlet (systemd services), with the nextcloud:33-fpm image, and postgresql database.

Details

Result of occ config:list system :

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "serverid": "0",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": ["***REDACTED**"],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "33.0.3.2",
        "overwrite.cli.url": "***REDACTED**",
        "htaccess.RewriteBase": "\/",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "maintenance": false,
        "default_phone_region": "FR",
        "theme": "",
        "loglevel": 2,
        "log_rotate_size": 10485760,
        "app_install_overwrite": [
            "integration_whiteboard",
            "files_markdown",
            "news"
        ],
        "maintenance_window_start": 1,
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "upgrade.disable-web": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_smtpauth": true,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpstreamoptions": {
            "ssl": {
                "verify_peer": false,
                "verify_peer_name": false
            }
        },
        "data-fingerprint": "1a0aa84bb341d90c17e4bea6ac46e19e"
    }
}

Quadlet files (equivalent to a docker compose) :

nextcloud.pod

[Unit]
Description=Pod nextcloud
After=collabora_code.container

[Pod]
PodName=nextcloud
PublishPort=8001:80

[Service]
Restart=always

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target

nextcloud_db.container

[Unit]
Description=Nextcloud DB (postgres)

[Container]
ContainerName=nextcloud_db
Pod=nextcloud.pod
Image=docker.io/library/postgres:17
AutoUpdate=registry
Volume=/opt/db/nextcloud/postgres:/var/lib/postgresql/data
EnvironmentFile=/home/nextcloud/container/.env

[Service]
Restart=always

nextcloud_redis.container

[Unit]
Description=Nextcloud cache (redis)

[Container]
ContainerName=nextcloud_redis
Pod=nextcloud.pod
Image=docker.io/library/redis
AutoUpdate=registry

[Service]
Restart=always

nextcloud_app.container

[Unit]
Description=Main nextcloud container
Requires=nextcloud_db.container
After=nextcloud_db.container
Requires=nextcloud_redis.container
After=nextcloud_redis.container

[Container]
ContainerName=nextcloud_app
Pod=nextcloud.pod
Image=docker.io/library/nextcloud:33-fpm
AutoUpdate=registry
Volume=/opt/data/nextcloud/data:/var/www/html
EnvironmentFile=/home/nextcloud/container/.env
Environment=POSTGRES_HOST=localhost
Environment=REDIS_HOST=localhost

[Service]
Restart=always

[delibury]

I was having the same problem with Nextcloud:fpm and podman on a Raspberry pi 5.

Disabling OPCache's JIT solved the problem. Thank you!!

Can this be disabled for disabled for non-x64 architecture please??

[jimsheen]

Corroborating this on a different SAPI, different image variant, different Nextcloud major, different aarch64 host — which between them rule out most of the plausible narrower causes. Same crash, same workaround.

Environment

Image	nextcloud:34.0.3-apache (mod_php, MPM prefork — not fpm)
PHP	8.5.9 (built 2026-08-05)
Arch	aarch64
Host	macOS on Apple Silicon, Docker Desktop 29.1.3 (not a Pi, not podman)
DB	postgres 17.11-alpine
Trigger	enabling the Deck app, 1.18.3

Symptom

Eleven seconds after the enable POST, every Apache worker began dying:

05:39:25  POST /ocs/v2.php/apps/appstore/api/v1/apps/enable   200
05:39:34  GET  /custom_apps/deck/img/deck.svg                 200
05:39:36  AH00052: child pid 13470 exit signal Segmentation fault (11)
          ...~40 crashes per 5 min, 100% of requests 502 including status.php

Two details that may be worth noting for triage:

1. Nothing appears in nextcloud.log. SIGSEGV kills the worker before PHP reaches its error handler, so the application log's newest entry was two days stale throughout a total outage. The only witness is the Apache parent reaping children. Anyone diagnosing this from Nextcloud's own logging will conclude nothing is wrong.

2. The container reported healthy for the entire outage. With the image's healthcheck at interval: 15s / retries: 20, Docker tolerates ~5 minutes of continuous total failure before flipping status. docker ps said Up 18 hours (healthy) while every request 502'd; only docker inspect revealed FailingStreak: 8 with every probe at ExitCode: 1.

The CLI/web asymmetry isolates the JIT

This is the part I think adds something beyond "me too". The image sets opcache.enable_cli => Off, so the CLI SAPI has no OPcache and therefore no JIT:

SAPI	opcache	JIT	Deck
CLI (occ)	enable_cli => Off	none	fine — occ app:list, occ app:enable deck both clean
Apache (web)	enable => On	jit=1255	segfault on every request

Identical code, identical app, identical container. Deck parses and loads without complaint; it only dies where the code is JIT-compiled. That points at JIT codegen rather than at the app.

Controlled test

I wrote down the reversal condition before running it — "if segfaults return with JIT off, the app is genuinely incompatible and this is not a JIT issue". It did not fire.

Stage	JIT	Deck	Requests	Segfaults
Original failure	1255	on	—	~40 / 5 min, all requests 502
Control	disable	off	40	0
Test	disable	on	120, hammering Deck's own routes	0
Fresh container, config from compose	disable	on	120	0

The last row recreates the container from scratch so the override can only come from the mount, not from leftover state. /index.php/apps/deck/ now returns a clean 401 auth challenge where it previously took the whole server to 502.

Same workaround as the original report — mounted read-only at /usr/local/etc/php/conf.d/zz-jit-disable.ini:

opcache.jit=disable
opcache.jit_buffer_size=0

Filename matters: conf.d is read alphabetically and the image's own opcache-recommended.ini sets jit=1255, so an override sorting before it is silently ignored — present in the container, doing nothing.

opcache.enable stays On; only codegen is off. For an I/O-bound workload like Nextcloud the measurable cost appears to be nil.

Scope — what I can and cannot claim

Every report I can find is aarch64 (this one, the two above, and linuxserver/docker-nextcloud#514). I have not tested x86-64 and am not claiming the JIT is safe there — only that the reports cluster on ARM.

Worth noting the setting arrived via #1863 → #1829, requested purely for performance with no architecture consideration; opcache.jit=1255 is the tracing JIT, historically the most crash-prone mode, and PHP 8.5 is weeks old. php/php-src#16829 (aarch64 tracing-JIT segfault) was a different bug, fixed in 2024 — so this looks like a later regression rather than that one resurfacing.

Offer

Happy to open a PR against Dockerfile-debian.template and Dockerfile-alpine.template, but the shape is your call and I would rather ask than guess:

1. drop the two jit lines entirely;
2. emit them conditionally on TARGETARCH (needs ARG TARGETARCH added — currently absent from both templates);
3. make them env-overridable, roughly what Added custom opcache config override #2275 proposes.

Say which you'd take and I'll put it together. If you'd prefer a minimal reproducer first, Deck on 34.0.3-apache reproduces it for me every time.

[J0WI]

This is a bug in PHP, so we can't do much about it here. Maybe it's related to php/php-src#22084 or php/php-src#22558.

Mounting a custom config that disables tracing or JIT entirely is the best you can do here.