    are supported and installed on your system.
## 2026-09-16T10:35:16Z M1 — OOM signals on THIS box (R-528). before:
limit=1342177280 oom=false restarts=0 status=running
81:          memory: 128M
134:          memory: 128M
## 2026-09-16T10:37:30Z after the 128M cap: false restarting 9
  cgroup: not visible
  docker oom events since 2026-09-16T10:35:29Z: 
  kernel OOM lines: 0
dmesg not readable in guest
2
## 2026-09-16T10:40:13Z cap restored: limit=1342177280 health=unhealthy restarts=10
    are supported and installed on your system.
## 2026-09-16T10:40:44Z memory lines now:
81:          memory: 1280M
112:          memory: 256M
134:          memory: 1280M
81:          memory: 1280M
112:          memory: 256M
134:          memory: 128M
## 2026-09-16T10:47:37Z paperless after fix: ws=unhealthy limit=1342177280 redis=134217728
## M1 RESULT (R-528), on THIS box (nested VM, customer LXC 9201, Docker in the guest):
##   cap 128M → paperless-webserver RESTARTING with RestartCount 9–10, and:
##     - docker inspect .State.OOMKilled = FALSE
##     - docker events --filter event=oom (since the cap change) = EMPTY
##     - the container's cgroup is NOT visible from inside the guest (find under /sys/fs/cgroup → nothing),
##       so memory.events / oom_kill could not be read there
##     - dmesg is not readable in the guest
##   So all three signals are silent here, exactly as on scratch 9202 (2026-09-15). BIGNIGHT's VM 333 did read
##   oomkilled=true for the worker-killed-inside-a-running-container shape; a MAIN-process kill + restart reports
##   nothing. The controller v0.243.0 OOM tag therefore cannot fire for this (restart) shape on a real box.
## MISTAKE, stated: my cap edit used a blunt sed, so the restore rewrote the REDIS limit too (128M → 1280M) —
##   the same mistake as 2026-09-15 on 9202. Repaired in the next step (redis back to 128M, webserver 1280M).
paperless-redis Up 7 minutes (healthy)
paperless-webserver Restarting (1) 57 seconds ago
paperless-postgres Up 12 minutes (healthy)
---
  File "/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py", line 256, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/db/backends/postgresql/base.py", line 332, in get_new_connection
    connection = self.Database.connect(**conn_params)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/psycopg/connection.py", line 120, in connect
    raise last_ex.with_traceback(None)
django.db.utils.OperationalError: connection failed: connection to server at "172.20.0.3", port 5432 failed: FATAL:  password authentication failed for user "paperless"
s6-rc: warning: unable to start service init-migrations: command exited 1
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
## 2026-09-16T10:48:27Z repairing paperless through the CONTROLLER's own path (my manual compose up broke its env):
  stop: {"ok":true,"message":"Stack paperless-ngx stop completed"}
 http=200
  start: {"ok":true,"message":"Stack paperless-ngx start completed"}
 http=200
  paperless state after the controller-driven restart: running at 2026-09-16T10:49:35Z
## MISTAKE, stated (2026-09-16): the M1 measurement recreated the paperless webserver with a bare
##   `docker compose up -d` INSIDE the guest. The controller injects the app's environment (DB password etc.) from
##   `app.yaml` at deploy time, so a hand-run compose brings the container up WITHOUT it: the webserver then failed
##   `password authentication failed for user "paperless"` against its own postgres and crash-looped.
##   Nothing about the product; the fault was the manual path. Repaired by restarting the stack through the
##   CONTROLLER's own stop/start API, which re-renders the environment. Lesson for the next measurement: drive app
##   containers through the controller, or set the cap via `docker update --memory`, never by re-running compose.
