Commit Graph

2909 Commits

Author SHA1 Message Date
Jim Warner
e5386f1f21 top: harden detailed stats two abreast summary display
When displaying detailed cpu statistics, as opposed to
those scalable graphs, only two per line can be shown.

Therefore, if we are showing a detail version, our '4'
toggle must prematurely revert to single mode display.

Conversely, the 't' toggle must also turn off that '4'
toggle rather than try to print more than 2 abreast if
we're currently executing in detailed statistics mode.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-20 18:50:55 +10:00
Jim Warner
5c5bff392b top: refined memory graphs two abreast summary display
When more than two cpus are displayed per summary area
line in graph form, those memory graphs were scaled to
that same width for consistency & aesthetics. However,
they probably shouldn't have been reduced to less than
terminal width due to a resulting loss of information.

[ after all, detailed memory stats are never reduced ]

So now, supporting logic was refactored to behave just
as it did before the 4 toggle was expanded beyond '1'.

[ the changes impact the 2 memory graphs exclusively ]

Reference(s):
https://www.freelists.org/post/procps/top-enhancements-2-bugs-swatted,1

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-13 19:55:17 +10:00
Jim Warner
3543172d4b top: additional tweaks for two abreast summary display
This patch just supplements the previous series with a
few minor tweaks representing some diverse objectives:

. a recent date for man page (which i always overlook)

. improved length calculations to maximize graph width

. a proper response to platforms with less than 8 cpus

. more consistency and readability with one blank line

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-13 19:54:33 +10:00
Jim Warner
fd529e9679 doc: top now has more than two abreast summary display
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
248efdf16e top: implemented more than two abreast summary display
Well, here it is. This is what the preceding series of
commits was leading to: an ability to show up to eight
cpus per Summary Area line. In reality, a self imposed
limit of four cpus on such lines seems more realistic.

In any case, the new capability could also be employed
along with that '!' toggle which consolidates adjacent
cpus into a solitary graph. When used together the '4'
and '!' toggles should accommodate any number of cpus.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
1c8028901e top: prepare for more than two abreast summary display
I guess the cat's out of the bag with the prior commit
message. It mentioned the objective of displaying more
than the current two cpu graphs on summary area lines.

On the way to that objective, this patch just prepares
our battlefield for the actual implementation in which
up to 8 individual cpu graphs will be shown on 1 line.

[ no logic has been impacted with this commit. we're ]
[ just adding one manifest constant, trading several ]
[ identifiers and updating some comments so the next ]
[ commit might be just a little bit more manageable. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
8c69e66a1a top: better graphic scaling in cpu/mem summary display
This program has always been sensitive to the width of
a terminal/console. The detailed cpu/memory statistics
plus all of those full screen replacement windows were
designed to fit within some 80 column, 24 row display.

When a user narrowed a gui terminal to less than those
dimensions, top would simply truncate the data to fit.
However, when displaying cpu/mem graphs instead of the
detailed statistics such truncation was not justified.
After all, such graphs were already scaled to 80 cols.

Henceforth, when in graph mode, truncation won't occur
until the graphs will no longer fit within 10 columns.

[ can you keep a secret? this change is really being ]
[ made in anticipation of showing more than just two ]
[ cpu graphs in the summary area on each screen row! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
2d5b51d1a2 top: refactor graph support of cpu/mem summary display
The logic (illogic?) in the sum_tics() and do_memory()
functions has grown to become almost unfathomable over
time. Additionally, though perhaps not apparent in the
code, many steps are duplicated within those routines.

So, this patch refactors all the summary graph support
to consolidate duplicated code and (hopefully) make it
more understandable with an eye to future maintenance.

[ additionally, that show_special guy's workload has ]
[ been reduced by eliminating any special directives ]
[ previously embedded in some cpu graphs even though ]
[ a cpu may have been idle during the last interval. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
08d0f377a7 top: eliminate that 'TOG4_NOTRUNC' compile conditional
When 2 abreast cpu display was introduced, the minimum
screen width was 160 columns so as to avoid (minimize)
truncation. Later that was reduced to 80 columns while
keeping the original minimum as a compile conditional.

In preparation for (virtually) eliminating these width
restrictions in a future patch this #define's history.

Reference(s):
. May, 2020 - introduced #define TOG4_NOTRUNC
commit be3dcaa842
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
d9c45988f7 top: eliminate that 'TOG4_NOFORCE' compile conditional
When two abreast display was introduce, in that commit
shown below, this #define provision was also added. It
actually was an artifact left from program development
and never made much sense in a real world application.

If activated it would make the '4' toggle appear to be
broken since it would only take affect if a user first
activated individual cpu display (the '1' toggle off).
And there was no error message offered to those users.

So, this questionable #define is now being eliminated.

Reference(s):
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
9d9993708b top: fix an improper behavior following a SIGWINCH bug
When top was made more responsive to keyboard input in
that commit referenced below, his previous response to
a SIGWINCH was upset. Formerly, that display integrity
was restored with the next refresh cycle. But, without
this patch, one must strike some key to accomplish it.

[ in truth, this patch vastly improves that sigwinch ]
[ response. whereas before, although integrity would ]
[ be restored automatically, it did not happen until ]
[ the next regular refresh. now it is instantaneous! ]

Reference(s):
. May, 2022 - made more responsive to kdb input
commit 3ea1bc779f

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Jim Warner
046883b9d3 library: address an 'uninitialised value' VALGRIND bug
Thanks to valgrind and his --track-origins=yes option,
the problem and solution was suggested as shown below.

[ and it was created in that commit referenced below ]

But, after attacking this problem by adding a memset()
call in pids.c, a 2nd valgrind oops, also shown below,
was encountered. The dynamically acquired 'cmd' again!

[ might help to explain why changes appear excessive ]

Reference(s):
. 1st valgrind discovery
==11111== Conditional jump or move depends on uninitialised value(s)
==11111==    at 0x13425D: stat2proc (readproc.c:582)
==11111==    by 0x137436: look_up_our_self (readproc.c:1613)
==11111==    by 0x132196: fatal_proc_unmounted (pids.c:1388)
==11111==    by 0x11BA4D: before (top.c:3580)
==11111==    by 0x127E10: main (top.c:7173)
==11111==  Uninitialised value was created by a stack allocation
==11111==    at 0x132165: fatal_proc_unmounted (pids.c:1381)

. Jul, 2022 - fatal_proc_unmounted refactored
commit 52bd019d8c

. 2nd valgrind discovery
==22222== 16 bytes in 1 blocks are definitely lost
==22222==    by 0x4A0E60E: strdup (strdup.c:42)
==22222==    by 0x133D00: stat2proc (readproc.c:587)
==22222==    by 0x136E67: look_up_our_self (readproc.c:1613)
==22222==    by 0x131BC7: fatal_proc_unmounted (pids.c:1390)
==22222==    by 0x11B7C6: before (top.c:3580)
==22222==    by 0x127828: main (top.c:7173)

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Craig Small
a8f1c50d3a nls: Update man-po for EIP updates
References:
 commit 3fa04fa947
2022-09-05 17:50:54 +10:00
Craig Small
65dac468e5 nls: Update translations for ignore ancestors
References:
 commit 4b44ab98c1
2022-09-05 17:46:40 +10:00
Eduardo Damato
3fa04fa947 docs: add info on why eip and esp are zeroed out 2022-09-04 13:48:45 -03:00
Rafael Kitover
20c328bdcc Improve trace().
Turn on trace() with the TRACE macro and remove the ## token paste
preprocessor operator which is unnecessary here and causes these errors:

ps/common.h:176:26: error: pasting "(" and ""ps_argv[thisarg] is %s\n""
does no t give a valid preprocessing token
.

Send trace output to STDERR.

Tracing can be enabled by adding TRACE to CPPFLAGS as follows:

./configure CPPFLAGS="-DTRACE"

Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2022-09-01 22:44:05 +00:00
Chris Down
2ba7e39f2b pgrep: Look at all ancestors in --ignore-ancestors
Previously we mistakenly only checked one previous level of the
hierarchy.

Signed-off-by: Chris Down <chris@chrisdown.name>
2022-08-31 10:25:49 +01:00
Craig Small
8eee6cc48c misc: Update NEWS/man date for pgrep -A
Added NEWS item
Update pgrep.1 date

References:
 commit 4b44ab98c1
2022-08-31 17:43:17 +10:00
Craig Small
d68c2d1a1c nls: Update man translations for new library
Library translations now use the new library and include
path.

References:
 commit 1502648ff9

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-31 17:40:50 +10:00
Chris Down
4b44ab98c1 pgrep: Add support for ignoring ancestors with -A/--ignore-ancestors
pgrep and friends naturally filter their own processes from their
matches. The same issue can occur when elevating with tools like sudo or
doas, where the elevating shim layers linger as a parent and are
returned in the results. For example:

    % sudo pkill -9 -cf someelevatedcmdline
    1
    zsh: killed     sudo pkill -9 -cf someelevatedcmdline

This is a situation we've actually seen in production, where some poor
soul changes how permission management works (for example with Linux's
hidepid option), needs to elevate a pgrep or pkill call, and now ends up
with more than they bargained for. Even after the issue is noticed,
resolving it requires reinventing some of the pgrep logic, which is
unfortunate.

This commit adds the -A/--ignore-ancestors option which excludes pgrep's
ancestors from the results:

    % sudo ./pkill -9 -Acf someelevatedcmdline
    0

We looks at multiple layers of the process hierarchy because, while
things like sudo only have one layer of shimming, some mechanisms (like
those found in a typical container manager like those found in Docker or
Kubernetes) may have many more.

Signed-off-by: Chris Down <chris@chrisdown.name>
2022-08-31 07:37:10 +00:00
Craig Small
deeb82411f build-sys: Fix paths for check-lib
Forgot to move the location for test_Itemtables

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-31 17:30:34 +10:00
Craig Small
f5ba25afe6 skill: Update include location too
skill got missed in the main update as its not compiled by
default.
2022-08-29 21:37:40 +10:00
Craig Small
2c3635b687 docs: Update manpages
Change include directory <procps/ -> <libproc2/
Change link instruction -lproc-2 -lproc2
2022-08-29 20:56:43 +10:00
Craig Small
b72eb5c9ea build-sys: Move git-version-gen
git-version-gen was the only file in misc/ moving it to local/
2022-08-29 20:53:01 +10:00
Craig Small
4ec809bc6f nls: Update translations for lib change
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 20:50:53 +10:00
Craig Small
55cc33fc0a misc: Update pc file to new library name 2022-08-29 20:42:45 +10:00
Craig Small
15a0a71406 testsuite: Update the library tests for new location
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 20:40:45 +10:00
Craig Small
1502648ff9 library: Rename to libproc2
The newlib library used to be called libproc-2 but the new
name is preferred.

References:
 https://www.freelists.org/post/procps/Next-for-newlib,3

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 20:38:17 +10:00
Craig Small
47a8676625 build-sys: Relocate lib/
test files in lib go to src/tests
include/ goes to local/
lib/*.c goes to local/

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 20:28:03 +10:00
Craig Small
dcce8038be build-sys: Need to add libary includes
The default path didn't add the library includes. A standard
build would work, but a make distcheck would not.
2022-08-29 19:16:49 +10:00
Craig Small
56db0bd32c build-sys: Update tests to new binary locations 2022-08-29 19:13:10 +10:00
Craig Small
3d0871728b build-sys: Relocate library to library/
All the dependent programs needed to have their includes moved too

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 19:02:44 +10:00
Craig Small
406b6d311c misc: Move Documentation to doc
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:38:52 +10:00
Craig Small
d78f10cb1e nls: Update translations to new source location
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:35:04 +10:00
Craig Small
4e9c4026e6 nls: Minor translation update
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:30:50 +10:00
Craig Small
dd60d6d6e8 misc: Move all binaries to src
*.c -> src/
ps/* src/ps/
top/* src/top/

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:29:28 +10:00
Craig Small
8e889ae682 build-sys: Rearrange the manual pages
All man pages are found in ./man
man-po -> po-man

References:
 https://www.freelists.org/post/procps/Next-for-newlib,3

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:07:43 +10:00
Craig Small
5fcf104cba build-sys: Removal of contrib directory
There is nothing we have used here for over a decade

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 17:46:03 +10:00
Craig Small
86c7eeb70d testsuite: Add test for fatal_proc_unmounted
Adding a check to ensure that fatal_proc_unmounted returns
values for things that do not just sit in /proc/self/stat

References:
 commit 52bd019d8c
2022-08-01 22:23:38 +10:00
Jim Warner
52bd019d8c library: refactor flawed function fatal_proc_unmounted
This commit addresses a potentially disastrous flaw in
that fatal_proc_unmounted() function wherein requested
item(s) might not have been returned to the caller yet
were specified at the time of a 'new' or 'reset' call.

The root cause, uncovered by Craig, was due to the old
library look_up_our_self() support function which only
would populate a proc_t with limited 'stat' file data.

This routine will now act the same as all other <pids>
functions which return a stack or stacks. Whatever was
specified with a 'new' or 'reset' will be returned, if
the passed 'return_self' parameter is other than zero.

[ as is so often the case, when flawed code is fixed ]
[ former complexity can be reduced as a side benefit ]

Reference(s):
https://www.freelists.org/post/procps/issue-245-plus-one,2

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-08-01 22:12:47 +10:00
Jim Warner
116ce62304 doc: revert mention of limits for fatal_proc_unmounted
With the next commit the fatal_proc_unmounted function
will be refactored to behave as it always should have.
So, a need for the user 'stat' caution will disappear.

Reference(s):
. original man page change
commit 7d44c94317

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-08-01 22:12:47 +10:00
Jim Warner
be5d03f855 ps: adapted to change of VSIZE_PGS item to VSIZE_BYTES
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-08-01 22:12:47 +10:00
Jim Warner
eb1bc8c273 library: change misnamed VSIZE_PGS item to VSIZE_BYTES
Gosh this particular flaw originated way back in 2015.

[ that was when we burdened a caller with additional ]
[ responsibilities for 'stacks_alloc', 'stacks_fill' ]
[ and 'stacks_dealloc'. damn implementation details. ]

Reference(s):
. Aug, 2015 - introduced<pids> api
commit 7e6a371d8a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-08-01 22:12:47 +10:00
Craig Small
7d44c94317 doc: Mention fatal_proc_unmounted limitations
Discovered this while trying to port programs that use the deleted
libprocps function look_up_our_self() which can be found with the
fatal_proc_unmounted() function.

While procps_pids_new() will allow you to specify any items you
care to think of, a subsequent call to fatal_proc_unmounted()
will only fill in the values found in /proc/self/stat.

Added a caveat to the procps_pids manpage pointing out this
limitation.

References:
 https://salsa.debian.org/xorg-team/app/apitrace/-/blob/debian-unstable/lib/os/os_memory.hpp#L44
 https://gitlab.com/-/snippets/2377884

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-07-27 21:12:10 +10:00
Jim Warner
80e2a7a682 top: eliminate a potential abend when exiting 'A' mode
In that issue cited below, Tyson Nottingham identified
a potential abend which was associated with 'alternate
display mode' plus that troublesome 'mkVIZrow1' macro.
He also offered a perfectly adequate fix for that bug.

I refer to that macro as troublesome since it's now so
widely used and sometimes (by design) causes 'begtask'
to go negative (invalid). And now I found yet one more
place where it should have been used but wasn't ('f').

It's also troublesome as evidenced by some git history
listed below. Heck, there was even a commit addressing
the same symptoms (alternate display mode abend) which
Tyson suffered. Clearly, the current design is flawed.

So, with those two issues in mind, I've refactored the
approach to maintaining a visible task in the 1st row.
Henceforth, a 'mkVIZrow1' macro will be issued in only
two places: once at startup and after most keystrokes.

Such an approach likely results in additional calls to
the 'window_hlp' routine that aren't really necessary.
But, it provides a cleaner design less prone to errors
in the future. Besides, such additional overhead would
only be incurred when interacting with the user. Thus,
new costs are of no concern and will never be noticed.

Reference(s):
. Tyson Nottingham reported problem
https://gitlab.com/procps-ng/procps/-/issues/245
. Jun, 2018 - visible row 1 tasks first addressed
commit 6aedeac667
. Jun, 2018 - adressed edge case, new bugs created
commit 9d59ddc466
. Sep, 2018 - additional edge case addressed
commit 59f02f19c7
. May, 2021 - some abends fixed, new error created
commit 8281ac4f98
. Jun, 2021 - try to prorect against future errors
commit 2ea082b4af
. Sep, 2021 - integrate mkVIZ & 'focused' tasks
commit 69978e3650

Discovered by: Tyson Nottingham
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-27 20:24:54 +10:00
Jim Warner
0df22d89db doc: make the library API pages a little more readable
Use of the the '.B' and '.BI' man documentation macros
had rendered the three library API pages less readable
than they could be. In addition, sometimes the pointer
indicator and an identifier were separated by a space.

So, this commit will trade those macros for some '.RI'
and '.RB' macros plus treat the pointers consistently.

[ plus we no longer italicize sort 'stacks' brackets ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-27 20:24:54 +10:00
Craig Small
813cefe96a nls: Update po files
Updates to cover the "new used" change and the pidwait change
2022-07-18 20:55:01 +10:00
Craig Small
95a253aa6e pgrep: Better warning if pidfd_open not implemented
If procps is built on a Linux 5.3+ system then pidwait
is built with pidfd_open(). If that program is run on
a system < 5.3 then it gives an odd generic error.

If we get a ENOSYS from one pid, we will get it for all
the others so its better to explain what happens and terminate.

The man page is updated to note this issue.

This came up due to killall in psmisc using pidfd_send_signal

References:
 https://bugs.debian.org/1015228

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-07-18 20:51:41 +10:00
Craig Small
bcce3e440a ps: Make STIME entries thread safe
Using localtime() can be a problem due to the static buffer for
the return value. It's simple enough to use localtime_r()

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-06-30 21:15:37 +10:00
Jim Warner
b0adacf1ea top: if line editing, account for invisible characters
If we're deleting a character or operating in overtype
mode, we must account for the potential of 'invisible'
characters. When one follows any character about to be
deleted or replaced both multi-byte sequences must go.

Without this change, there exists the possibility that
top might report some error where no error is apparent
to the user. For example, with 'other filtering' (o/O)
the user could see "unrecognized field name 'COMMAND'"
where the quoted column name appears perfectly normal.

Or maybe a sequences like the 'combining acute accent'
gets applied to an existing character instead of being
deleted as one expects when its parent was eliminated.

So, henceforth whenever any character is being deleted
we will now check for a following 'invisible' sequence
then eliminate it along with that preceding character.

[ admittedly, these scenarios are very rare yet they ]
[ may occur, especially when recalling some previous ]
[ multi-byte strings for editing. and, since we will ]
[ be interacting with a user, performance won't be a ]
[ factor so extra checks for a zero wcwidth is fine. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-30 20:55:27 +10:00