Adrian Cable Posted December 4, 2020 Posted December 4, 2020 From Armbian 20.08 onwards, I observed that htop loses its settings (e.g. show userland threads, process sort order) every boot. This is equally odd and frustrating, and until recently I had no idea what was happening to make this so. Then I discovered the cause - this script: /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx And indeed, on every reboot, it overwrites htoprc with some default settings. And I have tried but not succeeded to understand the intention was behind a decision to not allow users on SBCs to persistently change .htoprc any more. Can anyone add any context? Struggling to see how this makes sense, so any insight is valuable. Thanks!
Igor Posted December 5, 2020 Posted December 5, 2020 5 hours ago, Adrian Cable said: so any insight is valuable. We only want to tell htop which network interfaces is active, to display CPU and GPU temp where available. If we allow user to mess around, htop will crash. That is the reason. I agree its not the best way, but until we don't have better ... Your suggestions and PR with changes - that will not kill functionality - are welcome.
Adrian Cable Posted December 5, 2020 Author Posted December 5, 2020 Igor, sure, happy to suggest PR/changes. Can you tell me what user behaviour you are trying to guard against? I wasn't aware of any user-alterable parameters in htop that could cause it to crash. Thanks! 1
Igor Posted December 5, 2020 Posted December 5, 2020 8 hours ago, Adrian Cable said: Can you tell me what user behaviour you are trying to guard against? I wasn't aware of any user-alterable parameters in htop that could cause it to crash. Thanks! IIRC there was a problem with manipulating left and right metters. When we connect/disconnect to the wireless we add/remove wlan value and alter its location ... https://github.com/armbian/build/blob/master/packages/bsp/common/etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx#L38-L39 With a check here and there, we can probably remove defaulting each time ... Try hard to break it and then send a PR. I am happy if we can find better / proper approach.
Eric Poscher-Mika Posted January 16, 2021 Posted January 16, 2021 I made the same experience as Adrian. Many of us use armbian for production in Soho or as smart home appliance, so I think it should come as a proper Linux system, not Just as a development playground to be reflashed after a few days. This behaviour basically renders htop useless, because if you have e.g. nextcloud running you only see lots of threads of one server and this have to config htop every time again, which is so annoying! In 20 years of Debian usage I haven't seen any script messing with another packages configuration or a script rewriting all users configuration. Clearly this should be done on a different level and setting changes made by the user Sure we can find a better way to make this work, Here some ideas. -Does htop handle an a include statement in its config file, so we could have this changes made in one central place? -The relevant config options could be added at the bottom of the config files. First check for them. I made the same experience as Adrian. Many of us use armbian for production in Soho or as smart home appliance, so I think it should come as a proper Linux system, not Just as a development playground to be reflashed after a few days. This behaviour basically renders htop useless, because if you have e.g. nextcloud running you only see lots of threads of one server and this have to config htop every time again, which is so annoying! In 20 years of Debian usage I haven't seen any script messing with another packages configuration or a script rewriting all users configuration. Clearly this should be done on a different level. Sure we can find a better way to make this work, Here some ideas. -Does htop know something like a include statement in its config ffile -The relevant config options could be added at the bottom of the config files. First check for them. I made the same experience as Adrian. Many of us use armbian for production in Soho or as smart home appliance, so I think it should come as a proper Linux system, not Just as a development playground to be reflashed after a few days. This behaviour basically renders htop useless, because if you have e.g. nextcloud running you only see lots of threads of one server and this have to config htop every time again, which is so annoying! In 20 years of Debian usage I haven't seen any script messing with another packages configuration or a script rewriting all users configuration. Clearly this should be done on a different level. Sure we can find a better way to make this work, Here some ideas. -Does htop know something like a include statement in its config ffile -The relevant config options could be added at the bottom of the config files. -maybe it helps if you just uncomment the Line #13-14 # start with a clean copy # cp /etc/skel/.config/htop/htoprc "${homedir}"/.config/htop/htoprc
Igor Posted January 16, 2021 Posted January 16, 2021 3 hours ago, Eric Poscher-Mika said: Does htop know something like a include statement in its config ffile I think I tried that. 3 hours ago, Eric Poscher-Mika said: maybe it helps if you just uncomment the Line #13-14 Or copy config if not exists: [[ ! -f "${homedir}"/.config/htop/htoprc ]] && cp /etc/skel/.config/htop/htoprc "${homedir}"/.config/htop/htoprc File origin for PR: https://github.com/armbian/build/blob/master/packages/bsp/common/etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx 1
_r9 Posted January 19, 2021 Posted January 19, 2021 Moved to Feature Requests because this is more like an enhancement idea then a common issue
Eric Poscher-Mika Posted February 8, 2021 Posted February 8, 2021 Can you explain why/how it makes things worse?
Igor Posted February 8, 2021 Posted February 8, 2021 8 hours ago, Eric Poscher-Mika said: Can you explain why/how it makes things worse? If we don't start each time with a clean config, config is getting out of order and display of items messed up. I know current situation is not o.k., but this solution is also not. We need to find a better one. Until we don't, it's better to have the one that is less problematic.
Igor Posted May 23, 2021 Posted May 23, 2021 Current implementation was reported to have security issues: https://github.com/stealth/7350topless Any ideas how to do it properly without losing functionality and without much of rework? 2
Werner Posted May 23, 2021 Posted May 23, 2021 https://github.com/armbian/build/commit/f0f10a5b68aff3c766f2e8790ac4ce9f3c3e2160 1
tparys Posted May 27, 2021 Posted May 27, 2021 On 5/23/2021 at 5:57 AM, Igor said: Any ideas how to do it properly without losing functionality and without much of rework? How about this? NetworkManager htop dispatcher changed to only write to one root-owned file in a read-only spot, say /etc/armbian/htoprc (or whatever) Script detects if that global file doesn't exist yet, and executes a one-shot delete/replace that updates existing user htoprc files and replaces w/ symlink to that global location User's don't have access to global directory, so can't redirect or change dispatcher script behavior Users do have access to delete the symlink and replace with whatever they'd prefer in it's place Though, reading through the posts here, the simplest solution is to delete the dispatcher script altogether, and add it via an optional package if users would still want that functionality.
lanefu Posted May 27, 2021 Posted May 27, 2021 yeah deleting script makes sense.. So htop 3.x has network stuff built into it.. (I haven't tested it) Would be ideal to get to htop 3. and see if we can just bring over the minimal patches needed for the cpu stuff..... although we had some security stuff in our patches we had to recently addressed...so.. you know having someone that knows what they're doing in C would be good. https://github.com/armbian/build/tree/master/packages/extras-buildpkgs/htop/debian/patches
lanefu Posted May 27, 2021 Posted May 27, 2021 2 hours ago, tparys said: Though, reading through the posts here, the simplest solution is to delete the dispatcher script altogether, and add it via an optional package if users would still want that functionality. K we've pulled it out.. Hopefully we can get a permanent solution by next release https://github.com/armbian/build/pull/2850
Recommended Posts