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!

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.

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!

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.

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

 

 

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

The last looks good!

 

Merged. Will be fixed at next update.

Moved to Feature Requests because this is more like an enhancement idea then a common issue

I reverted fix since it makes things worse.

Can you explain why/how it makes things worse?
 

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.

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?

https://github.com/armbian/build/commit/f0f10a5b68aff3c766f2e8790ac4ce9f3c3e2160

Thanks @tkaiser 

 

I'll roll out update later on.

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?

1. NetworkManager htop dispatcher changed to only write to one root-owned file in a read-only spot, say /etc/armbian/htoprc (or whatever)
2. 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
3. User's don't have access to global directory, so can't redirect or change dispatcher script behavior
4. 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.

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

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