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>
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>
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>
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>
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#L44https://gitlab.com/-/snippets/2377884
Signed-off-by: Craig Small <csmall@dropbear.xyz>
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>
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>
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>
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>
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>
This commit just provides the final protection against
possible screen corruption when processing line input.
[ such corruption was limited to the input line only ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the library change calculating 'MEMINFO_MEM_USED'
top must be tweaked in order to retain the distinction
between non-cached used memory and cached used memory.
[ assuming one of the two graphs are being displayed ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some kdeinit tasks have a large environment consisting
mostly of nulls which were then followed by one or two
printable characters. Such strange environments should
not be shown with that 'not applicable' (n/a) notation
even though that first string vector is equal to '\0'.
I thought I had covered such a contingency but, due to
a misplaced right parenthesis, that '^N' bottom window
could see 'n/a' + a bunch of spaces + printable stuff.
Well, that won't happen anymore with this tiny change.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This program was well equipped to properly handle utf8
multi-byte characters - except for one important area!
If users typed any unicode character (shift+ctrl+u) or
pasted a utf-8 multi-byte string as a response to some
input prompt, those characters would simply be ignored
since they would not pass the internal 'isprint' test.
Well, now we can handle such data while preserving all
line editing provisions such as insertions, deletions,
destructive backspace, prior line recall (up/down) and
those all important cursor left plus right arrow keys.
[ we even support overtype mode for multi-byte stuff ]
[ even though our gui emulator will not let us alter ]
[ the cursor as confirmation (as we do at a console) ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Given that we won't always be able to alter the cursor
shapes (from underscore to block) if in input overtype
mode, this commit will at least provide a visual clue.
[ while this libvte quirk will impact gnome-terminal ]
[ and likely others, we're able to change the cursor ]
[ shape from underscore to block at a linux console. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the commit shown below the bottom window was forced
off if a full screen replacement function was invoked.
It did so by setting Frames_signal after calling those
routines from the keys_global function. However, there
was sometimes a possibility such action was premature.
At least two of those full screen replacement routines
may issue an error message & return without corrupting
the screen. As such, forcing off that bottom window is
totally unnecessary. It therefore should be preserved.
So this commit just moves the setting of Frames_signal
to the full screen replacement routines when possible.
Reference(s):
. May, 2022 - bottom window forced off for some
commit d66c1f39b5
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ along the way, we'll fix-up the section 4 commands ]
[ summary which has gotten a little outdated lately. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Messages issued by top will be displayed for only 1.25
seconds. And while this length of time would appear to
be acceptable (given the absence of complaints), there
will be times when a specific message might be missed.
So, this commit offers users the opportunity to recall
up to 10 of the most recent messages that were issued.
[ we'll just exploit top's new bottom window feature ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
During the changes to procps_loadavg I didn't set the initial
value for retval, meaning it was a random number.
It is now correctly intialised to zero.
References:
commit 8fcd14de18
