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)
* 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.


Thanks @Nightmayr for submitting the request.

@alexmurray makes sense.

We need /proc//fdinfo to report DRM usage statistics ( 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 ( and followed by Intel as of kernel 5.19.

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

1 Like