snap btop with AppArmor fills dmesg due to inability to read cpuset

[Sylvyrfysh]

Read the README.md and search for similar issues before posting a bug report!

Describe the bug

When using the btop snap on Ubuntu 24.04 LTS, every refresh triggers an AppArmor failure to read "/sys/fs/cgroup/cpuset.cpus.effective", which results in a dmesg like "[ 1927.402760] audit: type=1400 audit(1775318437.532:1062): apparmor="DENIED" operation="open" class="file" profile="snap.btop.btop" name="/sys/fs/cgroup/cpuset.cpus.effective" pid=112282 comm="btop" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0", making dmesg output hard noisy.

To Reproduce

1. Install snap btop
2. Run sudo dmesg --follow
3. Start btop
4. Observe failure

Expected behavior

btop snap outputs at most one audit failure for cgroup access failure

Info (please complete the following information):

• btop++ version: btop version: 1.4.6+6164470
  Compiled with: g++-14 (14.2.0)
  Configured with: make STATIC=true GPU_SUPPORT=false RSMI_STATIC=
  • If using snap: name: btop
    summary: Resource monitor that shows usage and stats
    publisher: James Tigert (kz6fittycent)
    store-url: https://snapcraft.io/btop
    contact: https://github.com/kz6fittycent/btop/issues
    license: Apache-2.0
    description: |
    Resource monitor that shows usage and stats for processor, memory, disks, network and processes.
    C++ version and continuation of bashtop and bpytop.
    commands:
• btop
  snap-id: UgRB8x3LtPA9L2Qo4G26ozMRImexxYzM
  tracking: latest/stable
  refresh-date: today at 10:21 CDT
  channels:
  latest/stable: 1.4.6 2026-04-01 (992) 2MB -
  latest/candidate: ↑
  latest/beta: ↑
  latest/edge: 1.4.6 2026-03-24 (992) 2MB -
  installed: 1.4.6 (992) 2MB -
• Binary: snap
• Architecture: x86_64
• Platform: Linux
• (Linux) Kernel: 6.17.0-20-generic

Additional context

===> btop++ v1.4.6
2026-04-04 (16:09:50) | DEBUG: Running in DEBUG mode!
2026-04-04 (16:09:50) | INFO: Logger set to DEBUG
2026-04-04 (16:09:50) | DEBUG: Using locale C
2026-04-04 (16:09:50) | DEBUG: TTY mode enabled: false
2026-04-04 (16:09:50) | DEBUG: Shared::init() : Initialized.

[ikt]

Yep same

2026-04-10T22:59:49.840042+10:00 server1 kernel: audit: type=1400 audit(1775825989.834:2057): apparmor="DENIED" operation="open" class="file" profile="snap.btop.btop" name="/sys/fs/cgroup/cpuset.cpus.effective" pid=586568 comm="btop" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
2026-04-10T22:59:51.837069+10:00 server1 kernel: audit: type=1400 audit(1775825991.835:2058): apparmor="DENIED" operation="open" class="file" profile="snap.btop.btop" name="/sys/fs/cgroup/cpuset.cpus.effective" pid=586568 comm="btop" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
2026-04-10T22:59:53.841077+10:00 server1 kernel: audit: type=1400 audit(1775825993.839:2059): apparmor="DENIED" operation="open" class="file" profile="snap.btop.btop" name="/sys/fs/cgroup/cpuset.cpus.effective" pid=586568 comm="btop" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

$ uname -a
Linux server1 6.8.0-107-generic #107-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 13 19:51:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble

[deckstose]

But we must check the file every iteration since it might change dynamically. btop itself doesn't produce the output, AppArmor does that every time btop tries to read the file.

[Sylvyrfysh]

@deckstose I agree with the fact it changes- it's very useful on my LXC setups to monitor my changing hardware allocations as I add or remove cpus/etc. This is more of a "if it fails to be read once (or 3x, or access denied, etc, can it stop attempting?"

[deckstose]

That would require context on why and how it fails, and if it's due to AppArmor denying access, stop trying. In other cases we could recover from it and should keep trying. But I would guess this is not viable (from btop's point of view).