Sorting stops working after awhile

[OliverJAsh]

I am using 3.0.5 (latest) and running:

sudo htop --sort-key=PERCENT_CPU

This works fine, but I have noticed that after it has been open for awhile, the rows are no longer sorted properly:

[fasterit]

What distro are you using and what is your CPU? Are you using a distro package or did you compile htop yourself?

What is "a while" in a timespec? How many minutes / hours / days?

A wild guess is that the display (what is indicated as being sorted) and the process tree (what is really sorted) de-sync. So a full screenshot would be helpful.

[OliverJAsh]

What is "a while" in a timespec? How many minutes / hours / days?

After ~10 minutes but sometimes it might take an hour. It varies.

What distro are you using and what is your CPU?

Does this help?

Are you using a distro package or did you compile htop yourself?

I installed htop using brew install htop.

So a full screenshot would be helpful.

I'm worried there might be sensitive data in there somewhere so I'm a bit hesitant to do that, but I can provide a screenshot of all columns except Command:

[OliverJAsh]

I don't know if it's a coincidence but when it does happen, the top row command is always WindowServer -daemon

[fasterit]

That was very helpful information, @OliverJAsh, thank you. It looks like it does not sort by the other shown columns.

[fasterit]

This seems to be related to the new (application) "sleep mode" in Mac OS "Big Sur". While this is on, htop freezes screen updates. And when it comes back it needs a few cycles to resort the process list.

So way to reproduce:

1. Let a Mac sit until "Big Sur" decides to power save by suspending application activity
2. htop display will eventually freeze or updates are not once every 1.5 seconds (or whatever --delay is) but much slower
3. "Wake" the system back up by pressing a key / starting an application
4. htop will show processes not well sorted by CPU
5. htop (in my testing) recovers within a few cycles as long at the system stays active

[OliverJAsh]

Interesting. What you're saying might be slightly different to what I'm seeing. I'm running this on a separate monitor and it's always visible. I can see it updating right now, but each cycle the sorting is incorrect. It doesn't ever resolve unless I restart the process.

https://user-images.githubusercontent.com/921609/106465613-18435200-6492-11eb-80bf-b47c069ac0d0.mov

[fasterit]

@OliverJAsh Try press a key in htop (up or down for example to move the highlighted process). Does that work again then?

[OliverJAsh]

I don't think that changes anything:

https://user-images.githubusercontent.com/921609/106599987-b8ac7b80-6551-11eb-9d3f-be7abcffb950.mov

[fasterit]

O.k., so we are looking for another bug besides the one fixed in https://github.com/fasterit/htop/commit/12f5f06e8855b653c98b75de55a45098bb468d57

Can you try to exit htop, rm / mv away your ~/.config/htop/htoprc and start htop again? I can't reproduce what you see so just trying to exclude a bugged htoprc.

If that doesn't work, does sorting by PID (key 'N') and the sorting by CPU% (key 'P') make the sort work again as intended?

What I find odd is that my brew install htop returns a non-unicode build (which makes sense per https://github.com/Homebrew/homebrew-core/blob/006d5dc2a852e6081c881c0b7bcd134c78156ddd/Formula/htop.rb but yours shows unicode in the header. Are you sure you are using the brew build of 3.0.5?

Yours should return, like mine:

$ which htop
/usr/local/bin/htop
$ md5sum /usr/local/bin/htop
e34dcf5bf82c5934ff090eec3ef8bd37  /usr/local/bin/htop

[OliverJAsh]

If that doesn't work, does sorting by PID (key 'N') and the sorting by CPU% (key 'P') make the sort work again as intended?

In the past I've tried something like that and it seems to fix it, until it happens again a while later.

Are you sure you are using the brew build of 3.0.5?

Yes.

$ htop --version
htop 3.0.5
$ which htop
/usr/local/bin/htop
$ md5 /usr/local/bin/htop
MD5 (/usr/local/bin/htop) = e34dcf5bf82c5934ff090eec3ef8bd37

Can you try to exit htop, rm / mv away your ~/.config/htop/htoprc and start htop again? I can't reproduce what you see so just trying to exclude a bugged htoprc.

I'll try this now and let you know if the issue occurs again or not.

[OliverJAsh]

Can you try to exit htop, rm / mv away your ~/.config/htop/htoprc and start htop again? I can't reproduce what you see so just trying to exclude a bugged htoprc

Unfortunately it's happening again.

[simonhf]

I'm also experiencing the issue, also on Big Sur, and also installed via brew install htop. Also, noticed that this bug seems to have been around since mid-2018 [1].

$ htop --version                             
htop 3.0.5
$ which htop 
/usr/local/bin/htop
$ md5 /usr/local/bin/htop 
MD5 (/usr/local/bin/htop) = e34dcf5bf82c5934ff090eec3ef8bd37

[1] https://github.com/hishamhm/htop/issues/810

[simonhf]

As a quick and dirty workaround, here's a one-liner which auto restarts htop every 300 seconds:

sudo perl -e 'while(1){ exit if(256 == system(qq[timeout --foreground 300 htop --delay=10 --sort-key=PERCENT_CPU])); }'

[fdutheil]

Hi, I've noticed this too, but as I'm not on MacOS (Gentoo Linux here, htop 3.0.5), I can open a new issue if we confirm the trigger is different. On my side, I can provoke the issue right after starting htop: to reproduce it, I just use up/down arrows to move the highlighting line, and the issue shows (when I move the HL line when a refresh occurs, the sort does not occur but values are refreshed). After a couple of refreshes without touching the keyboard, the sort seems to recover.

a bit more context: I upgraded recently from htop 2.x, and enabled the "treeview is always sorted by PID" option.

[fasterit]

@fdutheil That is not a bug, that is a feature. A few seconds after you move the cursor (highlighted bar) the sort stays stable otherwise you could not select multiple processes reliably. So this is not a bug and not what people describe here for MacOS.

[vahidpaz]

I have a workaround (if you could call it that):

For me the issue arises when I use any of the arrow keys; doing so causes the sort to be out of order until the 5th invocation of the Update Interval ("delay" variable in htoprc file). As long as I don't touch the arrow keys after the 5th invocation of delay, then the sort is fine. If I use an arrow key again, the same problem repeats. However, using the spacebar key to "tag" a process does provoke the problem.

Worded slightly a different way: if delay=15 in htoprc, after you press an arrow key you'll have to wait about 5*1.5= 7.5 seconds for the problem to fix itself.

I'm using Ubuntu 21.10, htop 3.2.0 installed via snap (sudo snap install htop).

This issue is probably related to the following as well:

• https://github.com/hishamhm/htop/issues/810
• https://unix.stackexchange.com/questions/454562/htop-sorting-cpu-column-incorrectly

cat /root/snap/htop/current/.config/htop/htoprc:

# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
htop_version=3.2.0
config_reader_min_version=3
fields=0 48 17 18 38 39 40 2 46 47 49 1
hide_kernel_threads=1
hide_userland_threads=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_deleted_exe=1
highlight_megabytes=1
highlight_threads=1
highlight_changes=0
highlight_changes_delay_secs=5
find_comm_in_cmdline=1
strip_exe_from_cmdline=1
show_merged_command=0
header_margin=1
screen_tabs=1
detailed_cpu_time=0
cpu_count_from_one=0
show_cpu_usage=1
show_cpu_frequency=0
show_cpu_temperature=0
degree_fahrenheit=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
enable_mouse=1
delay=15
hide_function_bar=0
header_layout=two_50_50
column_meters_0=AllCPUs Memory Swap
column_meter_modes_0=1 1 1
column_meters_1=Tasks LoadAverage Uptime
column_meter_modes_1=2 2 2
tree_view=0
sort_key=46
tree_sort_key=0
sort_direction=-1
tree_sort_direction=1
tree_view_always_by_pid=0
all_branches_collapsed=0
screen:Main=PID USER PRIORITY NICE M_VIRT M_RESIDENT M_SHARE STATE PERCENT_CPU PERCENT_MEM TIME Command
.sort_key=PERCENT_CPU
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0
screen:I/O=PID USER IO_PRIORITY IO_RATE IO_READ_RATE IO_WRITE_RATE PERCENT_SWAP_DELAY PERCENT_IO_DELAY Command
.sort_key=IO_RATE
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0

[BenBE]

The behavior you describe is actually intentional: When using the arrow keys htop interrupts the sorting for the process list to allow the user to follow/lookup processes that otherwise might jump around a lot due to the sorting by keeping the list stable for a certain time. As long as the sorting reactivates again after a (short) delay, this part of what you describe is intentional.

What do you mean by the part with the spacebar? Hitting space selects a process to perform one operation on multiple processes. This should not affect the sort order.

Also note, that sorting in tree-mode is performed on the tree-level among children. To sort globally you need to display the process view without the tree structure (switch with t.

[vahidpaz]

Oh okay that makes sense.

What I meant about the spacebar is exactly what you just described about its behavior. thx

[markus456]

Screencast from 2024-02-16 17-01-15.webm

It looks like the feature is a bit too aggressive at least on Fedora 39. Moving the mouse to the top left corner and bringing up the menu seems to count as a click. Same happens if I just double press the Windows key to bring the menu up and then close it.

Looks like turning off Setup -> Display options -> Enable the mouse prevents this from happening.

[BenBE]

Mouse input is input. Same explanation as above applies …