AppArmor: allow reading cgroup memory.max file

snapd
1

The opentelemetry-collector snap has a custom plug for some /proc and /sys files. I was trying to implement a new feature into the opentelemetry-collector charm which reads /sys/fs/cgroup/memory.max to throttle usage and avoid starving the host. However, I get a permission error:

2026-04-20T16:05:43.984Z error service@v0.147.0/service.go:165 error found during service initialization {“resource”: {“service.instance.id”: “7e51754c-7fed-43ed-8da3-e9413f915e38”, “service.name”: “otelcol”, “service.version”: “0.147.0”}, “error”: “failed to build pipelines: failed to create “memory_limiter” processor, in pipeline “traces/otelcol/0”: failed to get total memory, use fixed memory settings (limit_mib): open /sys/fs/cgroup/memory.max: permission denied”}

I tried to add /sys/fs/cgroup/memory.max to the snapcraft.yaml file, pack the charm, and copy it into the running charm. Then intsall it:

sudo snap install ./opentelemetry-collector_0.147.0_amd64.snap --dangerous
opentelemetry-collector 0.147.0 installed

sudo snap restart opentelemetry-collector
Restarted.

This did not resolve the problem as I still get the permission denied every time I restart the snap in the charm. What am I missing here? It seems snapd 2.65.1 featured AppArmor: allow reading cgroup memory.max file. Do I even need a snap plug, since I have > 2.65.1?

snap --version
snap          2.74.1+ubuntu24.04.4
snapd         2.74.1+ubuntu24.04.4
2

Was the plug connected after you installed the snap you built?

3

It was already connected previously and I did not manually have to connect it:

ubuntu@juju-4bcff3-0:~$ sudo snap connections opentelemetry-collector
Interface         Plug                                            Slot               Notes
...
system-files      opentelemetry-collector:etc-otelcol-config      :system-files      -
system-files      opentelemetry-collector:proc-sys-kernel-random  :system-files
4

Sorry, only now I noticed that you’re trying to write to /sys/fs/cgroup/memory.max. This is the root of the hierarchy, AFAIU the knobs for limiting resources are not exposed that this level - your limits are physical memory, physical CPUs etc. However you still have access to various pseudo files with stats. Assuming the memory controller is enabled, memory.maxwill be exposed at lower levels, e.g. /sys/fs/cgroup/system.slice/memory.max. I suspect you’re getting permission denied as the service is likely trying to write some value to /sys/fs/cgroup/memory.max which will just not work. This has nothing to do with the sandbox.

5

The upstream opentelemetry-collector workload tries to read this file, not write. That would be a crazy design choice for such a popular project. The log:

open /sys/fs/cgroup/memory.max: permission denied”

Does not indicate read/write, so this is not helpful.

6

Is there a denial from apparmor in dmesg then?

7

I am not sure, we have a workaround to handle this file with Python which is ran as root in a charm. We have an issue to pick this snap permissions issue up in the future and I will reach out again then. Thanks for the help for now.

8

The error comes from

specifically it’s surfaced from here when it’s not ENOENT:

If you observe it again, look for an apparmor denial in dmesg. If it’s deployed in a container e.g lxc, the denial may show up on the host.

If you want to confirm that the file is allowed by the interface, you can check the profile file /var/lib/snapd/apparmor/snap.opentelemetry-collector.opentelemetry-collector .

1 Like