Add actionToggle and fix LinuxProcessList_checkPidNamespace
Read cgroup file irrespective of flags
Improve logic to check if running in container
Add isContainerOrVMSlice()
Also change "(Process *)lp" to "proc"
Remove check for root slice
Remove Process_isRunningInContainer
Co-authored-by: BenBE <BenBE@geshi.org>
initscr(3) might fail, e.g. if the environment variable TERM is not set,
and directly exit the program. Thus redirect stderr afterwards to not
hide those potential fatal failure messages:
Error opening terminal: unknown.
linux/LinuxProcessList.c:1094:52: error: format specifies type 'char *' but the argument has type 'openat_arg_t' (aka 'int') [-Werror,-Wformat]
xSnprintf(filename, sizeof(filename), "%s/cwd", procFd);
~~ ^~~~~~
%d
linux/LinuxProcessList.c:1333:44: error: format specifies type 'char *' but the argument has type 'openat_arg_t' (aka 'int') [-Werror,-Wformat]
xSnprintf(path, sizeof(path), "%s/exe", procFd);
~~ ^~~~~~
%d
Supersedes: #1025
Searching man systemd(1) for "is-system-running" we see these states:
initializing
starting
running
degraded
maintenance
stopping
offline
unknown
Let's differentiate some more: green (ok) if state is "running", red (error)
if the state is unknown to htop or "degraded", yellow (warning) for
everything else (incl. "initializing", "starting", "maintenance" &
"stopping").
CRT.c:1015:14: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void CRT_done() {
^
void
Also increase the limit for nesting by using 64 bit integers.
ProcessList.c:242:36: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
#0 0x561cfec000a8 in ProcessList_buildTreeBranch ProcessList.c:242:36
#1 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#2 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#3 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#4 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#5 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#6 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#7 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#8 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#9 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#10 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#11 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#12 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#13 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#14 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#15 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#16 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#17 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#18 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#19 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#20 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#21 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#22 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#23 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#24 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#25 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#26 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#27 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#28 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#29 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#30 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#31 0x561cfebffec2 in ProcessList_buildTreeBranch ProcessList.c:243:7
#32 0x561cfebfb734 in ProcessList_buildTree ProcessList.c:312:10
#33 0x561cfebfb050 in ProcessList_updateDisplayList ProcessList.c:326:10
#34 0x561cfebfc58b in ProcessList_rebuildPanel ProcessList.c:374:4
#35 0x561cfec07953 in checkRecalculation ScreenManager.c:139:7
#36 0x561cfec07953 in ScreenManager_run ScreenManager.c:226:10
#37 0x561cfeb8899a in CommandLine_run CommandLine.c:378:4
#38 0x561cfeb6d6d4 in main htop.c:15:11
#39 0x7f14860291e9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#40 0x7f148602929b in __libc_start_main csu/../csu/libc-start.c:392:3
#41 0x561cfeaafb20 in _start (htop+0x105b20) (BuildId: fc4b9e52ffc111ca8b4cd53136a238414120a858)
In the situation where the currently displayed screen is
removed we could end up with an invalid ss pointer (and
associated index) in the global Settings structure. Any
subsequent access to these fields would make an invalid
pointer dereference.
Fixes: #1053
OpenFilesScreen.c:229:65: error: format specifies type 'unsigned long long' but the argument has type '__off_t' (aka 'long') [-Werror,-Wformat]
xSnprintf(fileSizeBuf, sizeof(fileSizeBuf), "%"PRIu64, st.st_size); /* st.st_size is long long on macOS, long on linux */
~~~~~~~~ ^~~~~~~~~~
If a fatal error occurs before CRT_init has been called, CRT_done
dereferences NULL in CRT_colors.
Simply check if CRT_crashSettings is not NULL, which is eventually
set when CRT_init has been called.
If it is not set, then do not try to disable ncurses.
Proof of Concept (on Linux):
$ ./configure --with-proc=/var/empty
$ make
$ ./htop
As the loop checks `tree_depth`, a tree build is needed to ensure
they're filled in correctly. Note that this breaks the display list sort
order in case it's non-tree-based (either startup in flat mode, or `*`
hotkey in flat mode), so the display list will need to be sorted again.
The PROCESS_MAX_UID_DIGITS=19 introduced in
696f79fe50 doesn't make sense.
The `uid_t` type does not require to be signed in POSIX. If we are to
support 64 bits as the maximum size of `uid_t`, then
PROCESS_MAX_UID_DIGITS should be 20. (= floor(log10(UINT64_MAX)) + 1).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
* The size of titleBuffer should be 257 bytes, not 256.
* Remove redundant `static char titleBuffer[]` delarations within
`alignedProcessFieldTitle()` and let the subroutine use one shared
buffer for printing field title. This reduces code size.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Title width of "CPUD%" and "SWAPD%" is 5 and there value cannot go
beyond "100.0%", so increase their field width to 5.
"IOD%" is similar to "MEM%" column, title width is 4 and maximum value
cannot go beyond "100.0%". So in case of "IOD%" column, there is no need
to increase title width to "5". "Process_printPercentage()" function
will handle the maximum value case, it will display value beyond "99.9%"
as "100" instead of "100.0".
Since commit edf319e[1], we're dynamically adjusting column width of
"CPU%", showing single digit precision also for values greater than
"99.9%" makes "CPU%" column consistent with all other values.
[1]: edf319e53d
Change "Process_printPercentage()" function's logic to always display
value (i.e. "val") with single precision. Except when value is greater
than "99.9%" for columns like "MEM%", whose width is fixed to "4" and
value cannot go beyond "100%".
Credits: @Explorer09, thanks for the patch[2] to fix title alignment
issue.
[2]: https://github.com/htop-dev/htop/pull/959#issuecomment-1092480951Closes: #957
Christian Göttsche
Nathan Scott
Anthony Ryan
valdaarhun
Christian Hesse
WHR
Tobias Stoeckmann
Daniel Lange
Benny Baumann
Denis Lisov
ilyam8
Explorer09
Kumar