Autoconnect requests for nvtop

Hi, I would like to request an auto-connect of the hardware-observe interface for nvtop. Nvtop is a htop like tool for GPUs. With the hardware-observe interface disconnected nvtop loses the ability to monitor GPU fan speeds (possibly other things as well that I haven’t noticed yet). process-control is needed for nvtop to kill processes.

The following is more of a half auto-connect request but for AMD GPUs, processes aren’t displayed unless both system-observe and kubernetes-support are connected. Nvtop shows the following apparmor denials if kubernetes-support isn’t connected:

= AppArmor =
Time: Sep 21 22:11:56
Log: apparmor="DENIED" operation="open" profile="snap.nvtop.nvtop" name="/proc/5962/fdinfo/" pid=147463 comm="nvtop" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /proc/5962/fdinfo/ (read)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/fdinfo/'

I think system-observe should be auto-connected but obviously kubernetes-support doesn’t make sense for nvtop. Would it make sense for the apparmor rule from the kubernetes-support interface: @{PROC}/[0-9]*/fdinfo/ r, to be added to an appropriate interface out of the ones being requested?

1 Like

+1 from me for auto-connect of hardware-observe for nvtop as this is standard functionality for the snap. kubernetes-support is far too privileged for this use-case - perhaps something like owner @{PROC}/[0-9]*/fdinfo/ r should either be in the base template for all snaps, or at least in the system-observe interface.

Hello,

Thanks @Nightmayr for submitting the request.

@alexmurray makes sense.

We need /proc//fdinfo to report DRM usage statistics (https://www.kernel.org/doc/html/latest/gpu/drm-usage-stats.html). Without that there is no way to report per-process usage of the GPUs.

It was first introduced by AMD in the kernel 5.14 (https://elixir.bootlin.com/linux/v5.14/source/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c) and followed by Intel as of kernel 5.19.

Shall we create a request to add fdinfo as part of system-observe?

1 Like

Can other @reviewers please vote on this request?

+1 from me for auto-connect of hardware-observe, too. I agree that kubernetes-support is way too generic for this.

Yes I think it is worth creating a PR against snapd to add this to system-observe.

+2 votes for, 0 votes against, granting auto-connect of hardware-observe for nvtop. This is now live.

I notice I forgot to vote on system-observe - +1 from me for auto-connect of this too.

+1 from me as well for auto-connect system-observe to nvtop. If a PR is created/merged then this should be enough. +2 votes for, 0 votes against. This is now live.