I’ve opened a “bug” with the developer from bpytop so he can assist in troubleshooting why this oddity is occurring with the snap (see screenshot):
As you can see, instead of / being printed, it’s printing dhcp. The snap&application use the latest version of psutil and both the dev and I are aware that something’s going on with psutil. However, this is a new bug (only affecting the snap) and so I decided to check to see if I could find anything else amiss. Here’s where I’m at so far:
gdb output:
gdb -ex="target remote :45753" -ex=continue -ex="signal SIGCONT"
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :45753
Reading /usr/lib/snapd/snap-gdbserver-shim from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /usr/lib/snapd/snap-gdbserver-shim from remote target...
Reading symbols from target:/usr/lib/snapd/snap-gdbserver-shim...
Reading /usr/lib/snapd/ddcb9bdfbe55f44b279cb8497e1fb50cc927ff.debug from remote target...
Reading /usr/lib/snapd/.debug/ddcb9bdfbe55f44b279cb8497e1fb50cc927ff.debug from remote target...
Reading /usr/lib/debug//usr/lib/snapd/ddcb9bdfbe55f44b279cb8497e1fb50cc927ff.debug from remote target...
Reading /usr/lib/debug/usr/lib/snapd//ddcb9bdfbe55f44b279cb8497e1fb50cc927ff.debug from remote target...
Reading target:/usr/lib/debug/usr/lib/snapd//ddcb9bdfbe55f44b279cb8497e1fb50cc927ff.debug from remote --Type <RET> for more, q to quit, c to continue without paging--
target...
(No debugging symbols found in target:/usr/lib/snapd/snap-gdbserver-shim)
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...
Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target...
Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
Reading /usr/lib/debug/lib/x86_64-linux-gnu//libc-2.31.so from remote target...
Reading target:/usr/lib/debug/lib/x86_64-linux-gnu//libc-2.31.so from remote target...
(No debugging symbols found in target:/lib/x86_64-linux-gnu/libc.so.6)
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading /lib64/ld-2.31.so from remote target...
Reading /lib64/.debug/ld-2.31.so from remote target...
Reading /usr/lib/debug//lib64/ld-2.31.so from remote target...
Reading /usr/lib/debug/lib64//ld-2.31.so from remote target...
Reading target:/usr/lib/debug/lib64//ld-2.31.so from remote target...
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
0x00007ff38c2d8169 in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
Continuing.
Program received signal SIGSTOP, Stopped (signal).
0x00007ff38c2d8169 in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
Continuing with signal SIGCONT.
--Type <RET> for more, q to quit, c to continue without paging--
Program received signal SIGCONT, Continued.
0x00007ff38c2d818b in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
Nothing much there that’s helpful…
Here’s the snap info:
snap-id: iH0DT1txUogChVISBwaxXrKZVCXifuTL
tracking: latest/edge
refresh-date: today at 09:11 CST
channels:
latest/stable: 1.0.49 2020-11-04 (159) 278kB -
latest/candidate: ↑
latest/beta: ↑
latest/edge: 1.0.50-3-g1f4e1e6 2020-11-07 (177) 278kB -
installed: 1.0.50-3-g1f4e1e6 (177) 278kB -
Here are it’s connections:
snap connections bpytop
Interface Plug Slot Notes
hardware-observe bpytop:hardware-observe :hardware-observe manual
home bpytop:home :home -
mount-observe bpytop:mount-observe :mount-observe manual
network bpytop:network :network -
network-control bpytop:network-control :network-control manual
physical-memory-observe bpytop:physical-memory-observe :physical-memory-observe manual
process-control bpytop:process-control :process-control manual
system-observe bpytop:system-observe :system-observe manual
So, on to apparmor:
Nov 7 11:58:57 ultra-magnus kernel: [ 7281.006604] audit: type=1400 audit(1604771937.093:256): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/etc/pop-os/os-release" pid=8328 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 7 11:58:57 ultra-magnus kernel: [ 7281.011154] audit: type=1400 audit(1604771937.097:257): apparmor="DENIED" operation="open" profile="snap.bpytop.bpytop" name="/etc/pop-os/os-release" pid=8328 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
I’m not well versed in apparmor but I know that it’s denying the request from bpytop to read /etc/pop-os/os-release. Is that innocuous? Is that actually a denial for the snap to read /etc?
Are these issues related at all? The question of our century perhaps? No, that’d be which direction the toilet paper is supposed to go… 
TIA.