[vpetersson-bot]

Issues Fixed

Fixes #3417.

Description

A process that crashes inside a container writes core.<pid> into its working directory. That is WORKDIR /usr/src/app: inside the container, on no mount, and reachable by no cleanup we have. The host's core_pattern is the kernel default core, a relative path, and core_uses_pid=1 means every crash adds a file rather than replacing one. ulimit -c is unlimited in a container by default, so nothing bounds it.

The result is invisible. docker images does not list it, and docker image prune cannot touch a live container's writable layer, so the space goes missing with nothing to account for it. A device in the field reached 24.2 GB of dumps in anthias-celery before its card filled: https://forums.screenly.io/t/sd-card-completely-full/6778

• ulimits: core: 0 on every service in all three compose templates, written as one anchor aliased everywhere else so the rule cannot drift between services or between the Debian and balena deployments.
• Tests asserting every service in every template resolves to core: 0. The real risk is a sixth service added later by someone who does not know this rule exists, so the test also checks the three templates agree on which services exist.

Changing the service definition also recreates the containers on the next upgrade, which discards the layer holding any dumps already accumulated. That is what repairs devices already affected.

Verification

Pi 4 testbed, Docker 29.6.1, containerd image store. Deployed through the real envsubst path rather than by hand editing the generated compose file.

Before, crashing Python three times inside anthias-celery:

-rw------- 1 root root 4861952 /usr/src/app/core.94
-rw------- 1 root root 4861952 /usr/src/app/core.101
-rw------- 1 root root 4861952 /usr/src/app/core.108

writable layer: 1.21MB -> 11.4MB

That size is what ties it to the field report: 4992 added paths under /usr/src/app there, and 4992 x 4861952 = 24.3 GB against the 24.2 GB observed.

After, with the patched template rendered and the stack brought up:

anthias-anthias-celery-1     ulimit -c = 0
anthias-anthias-server-1     ulimit -c = 0
anthias-anthias-viewer-1     ulimit -c = 0
anthias-redis-1              ulimit -c = 0

core files left by the previous run: 0   (the recreate cleaned them up)

Six crashes across celery and server then produced zero core files, and every writable layer stayed at its normal size (467kB / 1.21MB / 1.24MB / 4.1kB). Stack healthy afterwards: /api/v2/assets 200, celery 1 node online, viewer generating its asset list with both CEC adapters present. Testbed restored to baseline and its lock released.

Also confirmed the new test fails if a service loses the alias, rather than passing vacuously.

Tradeoff

This gives up core dumps on devices. Sentry already reports crashes, and nobody debugs a core file on a field SD card, so the dumps bought nothing while costing the card. docker-compose.dev.yml and docker-compose.test.yml are deliberately untouched: those run on workstations with room to spare, where a dump is actually useful.

Why the worker was crashing in the first place is a separate question and not addressed here. A crash should not cost the device its storage whatever the crash is.

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

🤖 Generated with Claude Code

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud