Ersetzt den wirkungslosen LD_PRELOAD-Versuch durch den dokumentierten
Root-Cause-Fix. immich_machine_learning blieb dauerhaft unhealthy: der
gunicorn-Worker haengt nach "Control socket listening" in futex und
erreicht nie "Application startup complete" (/ping -> Timeout). Ursache ist
der in gunicorn 25.1.0 neu eingefuehrte, fehlerhafte Control-Socket
(bestaetigt: gunicorn#3510, immich#27228, Regression seit Immich 2.6).
GUNICORN_CMD_ARGS=--no-control-socket deaktiviert das Feature. immich-ml
startet gunicorn als Subprozess (python -m gunicorn), der GUNICORN_CMD_ARGS
aus der Env liest und anhaengt; das Flag --no-control-socket
(config: control_socket_disable) ist in diesem gunicorn-Build als gueltig
verifiziert. Reversibel; bei gefixter Immich-Release wieder entfernen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
immich_machine_learning haengt seit dem 7.6. unhealthy: der gunicorn-Worker
bleibt nach "Control socket listening" in futex_do_wait stehen und erreicht
nie "Application startup complete" (/ping -> ConnectTimeout/ReadTimeout).
Kein OOM (22 GB frei), kein Disk-I/O-Wait, laeuft als root, Socket wird
erstellt - klassischer Fork-Deadlock von mimalloc (LD_PRELOAD) im geforkten
Worker unter gunicorn 25.1.0.
mimalloc per LD_PRELOAD="" deaktiviert. Reine Allocator-Optimierung,
funktional unkritisch, reversibel. Bekannte Upstream-Regression seit
Immich 2.6 (immich#27228, #22317) ohne offiziellen Fix; Restart und
force-recreate sind dort als wirkungslos dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Micha