Summary
I've noticed that the nextcloud-whiteboard container can accumulate zombie processes (defunct) over time in certain environments (especially on aarch64 Ubuntu). This typically happens when child processes (like those spawned by Node.js or Chromium) aren't properly reaped by the PID 1 process inside the container.
Observation
Monitoring the host system showed a significant number of zombie processes associated with the whiteboard container.
Command: ps -ef | grep defunct
Result: Accumulated 80+ zombie processes after several days of usage.
Recommended Solution
Adding init: true to the docker-compose.yml service definition effectively resolves this. It ensures that a minimal init binary acts as PID 1 and correctly reaps orphaned child processes.
YAML
services:
nextcloud-whiteboard:
...
init: true
Why this helps
Since Node.js does not handle signal forwarding and child process reaping as a full init system would, enabling the Docker --init flag (which uses tini) is a best practice for containers that spawn sub-processes.
I'm sharing this to help other users who might encounter similar issues, or perhaps it could be considered for the official documentation/example compose files.
Summary
I've noticed that the nextcloud-whiteboard container can accumulate zombie processes (defunct) over time in certain environments (especially on aarch64 Ubuntu). This typically happens when child processes (like those spawned by Node.js or Chromium) aren't properly reaped by the PID 1 process inside the container.
Observation
Monitoring the host system showed a significant number of zombie processes associated with the whiteboard container.
Command: ps -ef | grep defunct
Result: Accumulated 80+ zombie processes after several days of usage.
Recommended Solution
Adding init: true to the docker-compose.yml service definition effectively resolves this. It ensures that a minimal init binary acts as PID 1 and correctly reaps orphaned child processes.
YAML
services:
nextcloud-whiteboard:
...
init: true
Why this helps
Since Node.js does not handle signal forwarding and child process reaping as a full init system would, enabling the Docker --init flag (which uses tini) is a best practice for containers that spawn sub-processes.
I'm sharing this to help other users who might encounter similar issues, or perhaps it could be considered for the official documentation/example compose files.