BTOP having issues with segfault on hosts running zfs

snap
1

I’ve opened an issue with the upstream dev for btop given that the issue occurred with a recent commit to that repo. Once the edge channel was built, I refreshed and I started getting segfaults on my server running zfs.

2023/02/17 (10:43:11) | ===> btop++ v.1.2.13
2023/02/17 (10:43:11) | WARNING: Failed to join _runner thread on exit!

2023/04/02 (14:44:57) | ===> btop++ v.1.2.13
2023/04/02 (14:44:57) | WARNING: Failed to join _runner thread on exit!

2023/04/11 (16:06:33) | ===> btop++ v.1.2.13
2023/04/11 (16:06:33) | WARNING: Failed to join _runner thread on exit!

2023/05/20 (22:38:55) | ===> btop++ v.1.2.13
2023/05/20 (22:38:55) | WARNING: Failed to join _runner thread on exit!

2023/07/11 (10:06:37) | ===> btop++ v.1.2.13
2023/07/11 (10:06:37) | WARNING: Failed to join _runner thread on exit!

2023/08/29 (13:11:07) | ===> btop++ v.1.2.13
2023/08/29 (13:11:07) | WARNING: Failed to join _runner thread on exit!

2023/09/15 (11:22:09) | ===> btop++ v.1.2.13
2023/09/15 (11:22:09) | WARNING: Failed to join _runner thread on exit!

Here’s the apparmor entries for btop from my own server (this seems to be the issue, but I need verification):

Dec  3 21:33:41 $HOSTNAME kernel: [86683.983085] audit: type=1400 audit(1701660821.377:22788): apparmor="DENIED" operation="open" profile="snap.btop.btop" name="/proc/spl/kstat/zfs/data01/" pid=342556 comm="btop" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Dec  9 16:51:30 $HOSTNAME kernel: [147089.618050] audit: type=1400 audit(1702162290.182:38663): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.btop.btop" pid=377701 comm="apparmor_parser"
Dec  9 16:51:41 $HOSTNAME kernel: [147100.723776] audit: type=1400 audit(1702162301.286:38666): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.btop.btop" pid=377852 comm="apparmor_parser"
Dec  9 16:51:41 $HOSTNAME kernel: [147100.731233] audit: type=1400 audit(1702162301.294:38667): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.btop" pid=377854 comm="apparmor_parser"
Dec  9 16:51:45 $HOSTNAME kernel: [147104.876177] audit: type=1400 audit(1702162305.442:38670): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.btop.btop" pid=377944 comm="apparmor_parser"
Dec  9 16:51:51 $HOSTNAME kernel: [147110.742251] audit: type=1400 audit(1702162311.306:38671): apparmor="DENIED" operation="open" profile="snap.btop.btop" name="/proc/spl/kstat/zfs/data01/" pid=377951 comm="btop" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Dec  9 16:51:51 $HOSTNAME kernel: [147110.852715] btop[377983]: segfault at 0 ip 0000000000000000 sp 00007f07d6df0bf8 error 14 in btop[400000+1000]
Dec  9 16:54:02 $HOSTNAME kernel: [147241.740479] audit: type=1400 audit(1702162442.300:38674): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.btop.btop" pid=378228 comm="apparmor_parser"
Dec  9 16:54:02 $HOSTNAME kernel: [147241.746391] audit: type=1400 audit(1702162442.308:38676): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.btop" pid=378232 comm="apparmor_parser"
Dec  9 16:54:05 $HOSTNAME kernel: [147244.723834] audit: type=1400 audit(1702162445.284:38678): apparmor="DENIED" operation="open" profile="snap.btop.btop" name="/proc/spl/kstat/zfs/data01/" pid=378243 comm="btop" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

I appreciate any help, since this is a pretty popular snap and I’m not certain telling people to edit their apparmor configs is ideal. The issue does NOT exist in the stable channel, but does in the edge channel - for those wanting/willing to test. TIA!

2

Hi @kz6fittycent .

I think that, the issue is linked with the program btop, it executes operations that are in violation with the security profile defined for it. More precisely, it is refused to access to /proc/spl/kstat/zfs/data01/.

I think, there should be a strict security configuration which pushes to generate this error .

3

~ @kz6fittycent , one of the solutions is to refresh btop , you can execute this command :

sudo snap refresh btop

1 Like
4

have community_18

5

Actually, I am the snap maintainer for btop and the edge channel is the one giving us issues. The stable channel is working, hence my suspicion that the upstream dev made some changes to the code that is in violation of security settings, as you mentioned. I was really looking for confirmation to see if there were any changes made to apparmor that I wasn’t aware of, or if there are some snap-related security policies that are to blame.

6

@kz6fittycent , I tested your program, everything seems to be working fine .

The version btop executed is v( 1.2.13 ) on the divice :

Distributor ID: Ubuntu

Description: Ubuntu 22.04.3 LTS

Release: 22.04

Codename: jammy

7

I guess you either need to send a PR to extend the hardware-observe interface to allow reading this path or we might even need a separate zfs-observe interface here…

1 Like
8

Which channel? The problem definitely exists in edge. The stable channel is working as intended but I can’t move anything in edge, and the upstream developer considers anything in the master branch as “stable”. Meaning, no one can get any updates to their respective snaps. The stable version has been there since ~September 2023.

9

~ @kz6fittycent, with the stable channel .

10

You can follow the @ogra scenario . Perhaps, in this sense the bug will be solved .

11

Well, the bug is that the app segfaults, it should really prevent itself from doing this…

But since it seems to want to read zfs info, we should surely make access to that info available somehow in a snap interface, nonetheless the bug in the app itself should be fixed.

2 Likes
12

Yeah for clarity, and to avoid further confusion, stable works, edge, which contains the latest commits from the upstream developer, does not work with zfs. It is my belief that the fault lies with btop, but I was posting here to see if there were any updates to the interfaces (not likely) that could possibly cause the errors.

13

Upgrading to core22 fixed everything. :stuck_out_tongue: