Jump to content

very confused --> /etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx


Recommended Posts

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines