Addresses https://github.com/htop-dev/htop/issues/40; Rebased from https://github.com/hishamhm/htop/pull/809; Originally discussed in https://github.com/hishamhm/htop/issues/801

With inputs from @Explorer09, @BenBE, @marxin

1. On Linux a process is able to modify its own command name (/proc/pid/comm) say using prctl, and its own command line (/proc/pid/cmdline) say by writing into its arguments vector. But /proc/[pid]/exe is set by the kernel and provides the definitive location of the executable image. While the Command column currently displays cmdline, for the above reason it is desirable to display the executable image path and command name, along with cmdline, merging them where possible.

• In this pull request, two new optional columns are added: i) "Comm" - displays /proc/[pid]/comm if readable. It may not be readable for zombies. ii) "Exe" - displays 15 characters of the basename of /proc/[pid]/exe if readable. htop is able to read the /proc/[pid]/exe of ALL processes only when htop is either run with root privilleges (done with care) or given the capability CAP_SYS_PTRACE (sudo setcap 'cap_sys_ptrace=ep' /usr/bin/htop).

• A new option is added: "Merge exe, comm and cmdline in Command", toggled by the key 'm' If this option is unset (default for backwards compatibility), Command column displays cmdline as usual. If this option is set, exe, comm and cmdline are merged in the Command column, which is to be interpreted as follows: i) If no token is colorized, it implies htop didn't have permission to read /proc/[pid]/exe of the process, and htop has fallen back to displaying only cmdline.

  ii) If a token (which may have embedded spaces) is colorized, upto 15 bytes of it is understood to be comm. This implies htop was able to read the process' /proc/[pid]/exe and /proc/[pid]/comm. During display, htop first tries to find/merge comm in exe's basename; If that fails and also if the new option 'Try to find comm in cmdline' is set (default), htop tries to find/merge comm in cmdline (this may mis-identify a string in cmdline in very rare cases, say if comm or cmdline had been unsuitably modified). a) If comm was not merged into either exe or cmdline, three fields are displayed (with "│" as the field separator), the first being exe, the second comm, and the last cmdline. b) If comm was merged into exe or cmdline: If exe could not be merged with cmdline, two fields are displayed, the first being exe and the last cmdline; c) Otherwise, exe and cmdline are merged into a single field.

2. While htop currently sorts/filters the Command based always on cmdline, irrespective of whether it is full path or basename that is displayed, it is desirable to sort/filter based on what is displayed. After this change, Command is sorted/filtered based on what is displayed, whether it is exe or cmdline, full path or basename.

3. Implementation notes:

• Command Name (/proc/[pid]/comm) is displayed in a separate color (PROCESS_COMM)
• LinuxProcess_getCommandStr to return the displayed string (rather than cmdline always)
• When reading /proc/[pid]/cmdline, cmdline is concatenated with '\n' (instead of space) as delimiter; This helps when looking for comm in basenames of cmdline tokens with embedded spaces. Later during display in RichString_writeFrom, '\n' is translated into space. - LinuxProcess_writeCommand displays exe, comm, and cmdline as described above, retaining the existing options like basename display/highlighting

Hey bump into here by hacktoberfest :) I am exited doing something in such a well-known project.

(I want to believe) It closes #237

I hope it does what it expected to do but I would spend some time to verify it and test. And if there are any tests they may need to be updated.

Thank you for the htop

This is some refactoring work for makeCommandStr to make this suitable for platform independent use.

Changes include:

• Move cmdline, comm and exe to platform-independent Process structure.
• Move ProcessMergeCommand to platform-independent Process structure.
• Move procExeDeleted to platform-independent Process structure.
• Allow for individual activation/deactivation of highlighted components (basename, comm, deleted, separator, …)

The current state is mostly some PoC and still WIP.

This work is by @Explorer09, see original pull request (https://github.com/hishamhm/htop/pull/487). I rebased to current master to prepare this pull request.

Closes #49.

Example of TemperatureMeter using from comment below:

Also should be working on Raspberry Pi and maybe other ARM devices, which report cpu_thermal zone to sensors command (tested on Arch Linux ARM).

htop 3.1.2 crashes after some time (every time) at least whenever something is being compiled on Framework laptop with Intel i5-1135G7 CPU & 32 GB RAM.

Crash happened while ...

• building world;
• compiling ports/net/wifibox;
• compiling ports/devel/binutils.

uname -a FreeBSD luna 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n254246-6833ac673d9: Sat Apr 2 15:37:22 HST 2022 [email protected]:/build/world/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64

Edited captured output via script(1) ...

... FATAL PROGRAM ERROR DETECTED

Please check at https://htop.dev/issues whether this issue has already been reported. If no similar issue has been reported before, please create a new issue with the following information:

• Your htop version: '3.1.2'
• Your OS and kernel version (uname -a)
• Your distribution and release (lsb_release -a)
• Likely steps to reproduce (How did it happen?)
• Backtrace of the issue (see below)

Error information:

A signal 6 (Abort trap) was received.

Setting information:

htop_version=3.1.2;config_reader_min_version=2;fields=48 3 0 46 47 39 49 20 53 6 18 2 99 1;sort_key=20;sort_direction=1;tree_sort_key=0;tree_sort_direction=1;hide_kernel_threads=1;hide_userland_threads=0;shadow_other_users=0;show_thread_names=0;show_program_path=1;highlight_base_name=1;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;tree_view=0;tree_view_always_by_pid=0;all_branches_collapsed=0;header_margin=0;detailed_cpu_time=0;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=1;show_cpu_temperature=0;degree_fahrenheit=0;update_process_names=0;account_guest_in_cpu_meter=0;color_scheme=6;enable_mouse=1;delay=15;hide_function_bar=0;header_layout=two_50_50;column_meters_0=LoadAverage AllCPUs2 MemorySwap ZFSCARC ZFSARC;column_meter_modes_0=2 1 1 2 2;column_meters_1=System Hostname Uptime DateTime Battery DiskIO NetworkIO;column_meter_modes_1=2 2 2 2 2 2 2;

Backtrace information:

0: 0x21c842 /usr/local/bin/htop (CRT_handleSIGSEGV+0x102) [0x21c842]
1: 0x8270aa5a0 /lib/libthr.so.3 (_fini+0) [0x8270aa4d0]
2: 0x8270a9b5f /lib/libthr.so.3 (_fini+0) [0x8270a9a20]
3: 0x7ffffffff2d3 ? (+0) [0x7ffffffff2d0] {signal frame} 4: 0x82448edfa /lib/libc.so.7 (_fini+0) [0x82448edf0] {signal frame} 5: 0x8270a9a20 /lib/libthr.so.3 (_fini+0) [0x8270a9890]

To make the above information more practical to work with, please also provide a disassembly of your htop binary. This can usually be done by running the following command:

objdump -d -S -w which htop > ~/htop.objdump ...

I will attach "objdump" output & backtrace. For future, is backtrace needed when "objdump" output is also provided?

htop.objdump.txt htop.gdb.bt-full.txt

htop 3.0.3-1

model name : Intel(R) Celeron(R) CPU N3160 @ 1.60GHz

sensors:

Core 0:       +40.0°C  (high = +90.0°C, crit = +90.0°C)
Core 1:       +41.0°C  (high = +90.0°C, crit = +90.0°C)
Core 2:       +36.0°C  (high = +90.0°C, crit = +90.0°C)
Core 3:       +43.0°C  (high = +90.0°C, crit = +90.0°C)

htop:

  1[||||||                 4.8%  800MHz 41°C]   3[                           0.0%  655MHz 36°C]
  2[||||||||               8.3%  802MHz 36°C]   4[||||||||||                 10.7%  656MHz N/A]

its great and all this is still maintained, but I dont enjoy things becoming less readable. you could argue here "use a better font" but htop is used in a lot of minimal installs that might be lacking all and any fancy glyphs, which is why the old method of checkmarks is used in nearly every cli program

Implements support for arbitrary Performance Co-Pilot metrics with per-process instance domains to form new htop columns. The column-to-metric mappings are setup using configuration files which will be documented via man pages as part of a follow-up commit.

We provide an initial set of column configurations so as to provide new capabilities to pcp-htop: including configs for containers, open fd counts, scheduler run queue time, tcp/udp bytes/calls sent/recv, delay acct, virtual machine guests, detailed virtual memory, swap.

Note there is a change to the configuration file path resolution algorithm introduced for 'dynamic meters'. First, look in any custom PCP_HTOP_DIR location. Then iterate, in priority order, users home directory, then local sysadmins files in /etc/pcp/htop, then readonly configuration files below /usr/share/pcp/htop. This final location becomes the preferred place for our own shipped meter and column files.

The Settings file (htoprc) writing code is updated to not using the numeric identifier for dynamic columns. The same strategy used for dynamic meters is used here where we write Dynamic(name) so the name can be setup once more at start. Regular (static) columns writing to htoprc - i.e. numerically indexed - is unchanged.

This implementation makes NetBSD use htop(1) without the need of mount_procfs(8).

The implementation has been copied over and modified from the OpenBSD implementation in htop(1).

Make NetBSD no longer masquerade as Linux.

I'm using htop on one of my servers also running various docker containers. In that case, htop can be very confusing due to the high amount of different processes.

It would be really helpful if there would be a switch to only show processes not running in a container (i.e. running directly on the host).

It is fairly common for a infecting malware to impersonate as a Linux kernel thread by using similar naming style(e.g. ksoftirqd/0) to go off the hook upon a security audit:

While for htop it is already quite easy to identify them via the toggling of the "Hide kernel threads" display options in the setup view, it would be great if htop can highlight them in the first place(like, in red, blinking text) to further alert there's a potential malware in the system.

Currently, tree-view is almost useless for finding resource hogs. The reason is that sorting on e.g. CPU use in tree-view mode, will sort the process tree based on the CPU use of the parent, rather than the total.

Adding columns for total CPU/memory use for a process tree would allow the user to sort on the total to surface the process trees that hog the most resources, yet retain the ability to inspect the constituent processes and threads individually.

It is possible that users might want to sort on total CPU for the tree but without showing the column. Therefore, a further improvement would be to add an option that, in tree-mode, sorting on resource columns will sort on the total for the tree.

There are a few existing suggestions related to total resources. Here's how this one differs:

• This is different from #920 since sorting process trees will need the total no matter if they're collapsed or expanded.
• This is different from #301 since 1) it is defined exactly rather than reliant on a heuristic and 2) it retains the ability to inspect the process tree of an application.
• This is different from #81 since 1) it is about showing totals for all rather than just the selected process and 2) thereby allow sorting process trees.

When zswap is enabled and in use on a Linux system, htop output does not reflect this in any way. This leads to two issues:

1. Compressed pool state is not communicated to the user (this is less important),
2. Zswapped pages are accounted to swap usage, which is misleading (this is more important).

As of Linux 5.19, zswap metrics can be read from /proc/meminfo and no longer require debugfs. Use this to provide zswap support in two ways:

• highlight the compressed pages on the RAM gauge as a separate type of RAM usage (but still account them as "used" RAM),
• highlight the frontswapped pages on the Swp gauge as a separate type of swap usage, and discount them from the "used" swap because these pages are not physically residing on the swap device.

(Note: we still want to highlight the frontswapped pages on the Swp gauge, because frontswap will only work when there is enough physical swap to evict the frontswapped pages all the way to the backing device. Thus it is important to give the user an insight into this metric.)

Fixes #104. Potentially closes #721.

I'm using htop 3.2.1 in Gentoo Linux. Whenever the Tree view and Display threads are enabled, the vertical line to the left of the last process in the list is missing.

Use single precision floating point numbers for calculations where the reduced precision is sufficient enough.

May save some cycles on architectures not supporting double precision arithmetic in hardware.

I just start htop, and it crashed.

❯ htop


FATAL PROGRAM ERROR DETECTED
============================
Please check at https://htop.dev/issues whether this issue has already been reported.
If no similar issue has been reported before, please create a new issue with the following information:
  - Your htop version: '3.2.1'
  - Your OS and kernel version (uname -a)
  - Your distribution and release (lsb_release -a)
  - Likely steps to reproduce (How did it happen?)
  - Backtrace of the issue (see below)

Error information:
------------------
A signal 11 (Segmentation fault) was received.

Setting information:
--------------------
htop_version=3.2.1;config_reader_min_version=3;fields=53 48 3 4 0 51 18 113 20 53 17 114 18 38 39 40 2 46 47 49 1;hide_kernel_threads=1;hide_userland_threads=0;shadow_other_users=0;show_thread_names=1;show_program_path=1;highlight_base_name=1;highlight_deleted_exe=1;highlight_megabytes=1;highlight_threads=1;highlight_changes=1;highlight_changes_delay_secs=1;find_comm_in_cmdline=1;strip_exe_from_cmdline=1;show_merged_command=1;header_margin=1;screen_tabs=0;detailed_cpu_time=1;cpu_count_from_one=0;show_cpu_usage=1;show_cpu_frequency=1;show_cpu_temperature=1;degree_fahrenheit=0;update_process_names=1;account_guest_in_cpu_meter=1;color_scheme=0;enable_mouse=0;delay=10;hide_function_bar=0;header_layout=two_50_50;column_meters_0=AllCPUs;column_meter_modes_0=1;column_meters_1=Memory Tasks LoadAverage Hostname Uptime DiskIO NetworkIO Systemd CPU;column_meter_modes_1=1 2 2 2 2 2 2 2 1;tree_view=0;sort_key=46;tree_sort_key=46;sort_direction=-1;tree_sort_direction=-1;tree_view_always_by_pid=1;all_branches_collapsed=0;screen:Main=ELAPSED USER PPID PGRP PID TGID NICE OOM STARTTIME ELAPSED PRIORITY IO_PRIORITY NICE M_VIRT M_RESIDENT M_SHARE STATE PERCENT_CPU PERCENT_MEM TIME Command;.sort_key=PERCENT_CPU;.tree_sort_key=PERCENT_CPU;.tree_view=0;.tree_view_always_by_pid=1;.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;

Backtrace information:
----------------------
htop(+0x12dcc)[0x564d0598edcc]
htop(CRT_handleSIGSEGV+0xe9)[0x564d05997269]
/usr/lib/libc.so.6(+0x38a00)[0x7f70bed8aa00]
htop(Process_updateCPUFieldWidths+0x0)[0x564d0599c560]
htop(+0x3cfe5)[0x564d059b8fe5]
htop(+0x3cb2e)[0x564d059b8b2e]
htop(+0x2a646)[0x564d059a6646]
htop(ScreenManager_run+0x5aa)[0x564d059a706a]
htop(CommandLine_run+0x43e)[0x564d0599775e]
/usr/lib/libc.so.6(+0x23290)[0x7f70bed75290]
/usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7f70bed7534a]
htop(_start+0x25)[0x564d0598d075]

To make the above information more practical to work with, please also provide a disassembly of your htop binary. This can usually be done by running the following command:

   objdump -d -S -w `which htop` > ~/htop.objdump

Please include the generated file in your report.
Running this program with debug symbols or inside a debugger may provide further insights.

Thank you for helping to improve htop!

[1]    1369654 segmentation fault (core dumped)  htop