When some cleanup was performed on the readproc module
in the commit shown below, some residual code involved
with the 'did_fake' flag remained. Since such logic no
longer served any real need, this patch will whack it.
Reference(s):
. cleanup of readproc functions
commit 887bb51016
Signed-off-by: Jim Warner <james.warner@comcast.net>
No libprocps user expects signal values to be returned
as 'long long' quantities. More importantly the <PIDS>
api only returns a 'str' result for signal categories.
So this patch eliminates all the conditional code that
depends on the absence of the #define 'SIGNAL_STRING'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will just correct an oops introduced in the
commit shown below. Thank goodness both 'str' & 'strv'
occupy the same storage location in that result union.
Reference(s):
. standardize 'errno' management
commit 06be33b43e
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beyond the copyrights, the single oops in the man page
was introduced in the commit which is referenced below
dealing with some cleanup following that Qualys audit.
Reference(s):
. man page error introduced
commit e531c78140
Signed-off-by: Jim Warner <james.warner@comcast.net>
@MarsChan correctly pointed out that the read() always returns 128
bytes, so skipping on >= 128 will always mean we skip. Their suggestion
was to remove the equality, but read will never go past 128 bytes so
I just removed that part of the check.
References:
procps-ng/procps!89
With the two preceding 'catch up' patches, this newlib
NEWS can now be made identical to that master version.
[ it's assumed any releases prior to 3.3.15 have all ]
[ been represented under newlib (where appropriate). ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will just parallel a pending master branch
merge request referenced below. Note, however, that it
is not really needed in this newlib branch because the
procps_pids_select() function itself provides a 'zero'
delimiter with every caller's designated list of pids.
[ since it's required under the master branch, we're ]
[ repeating it here just for documentation purposes. ]
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/86
Originally-by: Yoann Lecuyer <yoann.lecuyer@gmail.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
The backtrace shown in the bug report referenced below
illustrates a 'normal' program termination interrupted
with some signal, ultimately then causing a top crash.
So this commit just rearranges a little code such that
all signals will be blocked during that rather lengthy
end of program processing regardless of how initiated.
[ in that report, ignore the assertion regarding the ]
[ '-n' option. it obviously was not '1' since do_key ]
[ had been called, which otherwise wouldn't be true. ]
[ and when it is '1' the -d option would be ignored. ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1737552
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit most significant change is the elimination
of the kbd_ENTER entry from that tinfo_tab in iokey().
That entry was a useless artifact left from the commit
which is shown below. It makes no sense to 'translate'
a keystroke into something it already was (i.e. '\n').
The remaining changes just reorder those table entries
for a progression consistent with vim keys: h,j,k & l.
Reference(s):
. fix 'iokey()' flaw preventing proper translations
commit c3323bdb68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Short separator option used 's' instead of 'S' which
meant it pidof would use the single-shot option when you
meant separator.
Added alias for -S using -d to give some sysvinit pidof
compatibility.
References:
commit 73492b182dprocps-ng/procps#141
Short separator option used 's' instead of 'S' which
meant it pidof would use the single-shot option when you
meant separator.
Added alias for -S using -d to give some sysvinit pidof
compatibility.
References:
commit 73492b182dprocps-ng/procps#141
watch used to check if COLOR was required, check if color was
possible then.. set the flag again.
It should have been cleared after failing to get colors out of
ncurses.
References:
procps-ng/procps#143
watch used to check if COLOR was required, check if color was
possible then.. set the flag again.
It should have been cleared after failing to get colors out of
ncurses.
References:
procps-ng/procps#143
The backtrace shown in the bug report referenced below
illustrates a 'normal' program termination interrupted
with some signal, ultimately then causing a top crash.
So this commit just rearranges a little code such that
all signals will be blocked during that rather lengthy
end of program processing regardless of how initiated.
[ in that report, ignore the assertion regarding the ]
[ '-n' option. it obviously was not '1' since do_key ]
[ had been called, which otherwise wouldn't be true. ]
[ and when it is '1' the -d option would be ignored. ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1737552
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit most significant change is the elimination
of the kbd_ENTER entry from that tinfo_tab in iokey().
That entry was a useless artifact left from the commit
which is shown below. It makes no sense to 'translate'
a keystroke into something it already was (i.e. '\n').
The remaining changes just reorder those table entries
for a progression consistent with vim keys: h,j,k & l.
Reference(s):
. fix 'iokey()' flaw preventing proper translations
commit 42f0a341ba
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit standardizes the behavior of the PgUp/PgDn
keys when on the main top display. With PgDn, the last
process will become the first process. With PgUp, that
first task will now appear as the last task displayed.
[ this also eliminates some quirks that were evident ]
[ when paging at or near the end of the process list ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent issue (and merge request) reminded me of gaps
in top's alternate 'vim' navigation keys support. Some
xterm emulators do not pass the customary strings when
keys were used with the <Ctrl> and/or <Alt> modifiers.
While it was a known problem, this issue/merge request
prompted research into the root cause. As it turns out
the problem is traceable to an X resource known by the
name 'eightBitInput'. When 'true' (the default), a key
pressed in combination with <Alt> will not be preceded
by the <Esc> character. Rather, a single character was
presented (modified via an 'eightBitMeta' X resource).
The following approaches would eliminate this problem:
. start xterm thus: xterm -xrm '*eightBitInput: false'
. use: ~/.Xresources with 'Xterm*eightBitInput: false'
. build xterm with 'configure --enable-meta-sends-esc'
( apparently used for CentOS, Fedora, openSUSE, etc. )
. enable xterm's menu via 'configure --enable-toolbar'
( so the user can set the 'Meta Sends Escape' option )
Of course, none of the above steps is desirable from a
user's perspective. So, this patch will add additional
entries to the iokey function's tinfo_tab to represent
strings passed when the <Alt> key does not send <Esc>.
[ hopefully they'll be the same across all platforms ]
Lastly, this patch will also eliminate those redundant
<Atl> + '\', '/', '<' & '>' provisions, which now seem
like overkill and suffer from that same 'eightBitMeta'
xterm problem. And we might as well say goodbye to the
4 '<Alt> + arrow key' table entries (which do not seem
to currently work with any emulator which I can find).
[ what in the world was I thinking way back in 2011? ]
Reference(s):
. issue
https://gitlab.com/procps-ng/procps/issues/135
. merge request
https://gitlab.com/procps-ng/procps/merge_requests/84
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just implements an equivalent to the master
branch 'CPU_ZEROTICS' provision. However, the original
impetus for that earlier implementation was ultimately
attributed to a likely kernel anomaly since corrected.
As a result, in this newlib implementation we take the
opposite approach to the default behavior. There is no
adjustment to TIC_SUM_DELTA values if fewer ticks than
expected are recorded, unless the define is activated.
The commit shown below explains why the 'CPU_ZEROTICS'
define was retained in spite of the fix to the kernel.
Reference(s):
. issue referencing CPU_ZEROTICS
https://gitlab.com/procps-ng/procps/issues/132
. master branch CPU_ZEROTICS summary
commit ee3ed4b45e
. lengthy thread leading to CPU_ZEROTICS
https://www.freelists.org/post/procps/CStates-handling-new-switch
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some parts of our newlib implementation are the result
of functions which have been propagated from module to
module. In particular, those 'cleanup_stacks' routines
are all similar & likely originated in the <pids> api.
In that interface there was a need to free dynamically
acquired memory before the result structure was reused
to satisfy subsequent 'get', 'select' or 'reap' calls.
This, in turn, led to a concept of 'dirty' stacks with
the need to call one of two 'cleanup_stack' functions.
None of the remaining interfaces deal with such memory
yet they each had their own 'cleanup_stack' functions.
Those functions were responsible for resetting each of
the result unions to zero, excluding any 'noop' items.
The bottom line is that for all interfaces, repetitive
calls would require iterating through the stack(s) two
separate times: once to 'cleanup' another to 'assign'.
With this commit we will reduce iterations to just the
'assign' routine. A reset to zero will be accomplished
in the 'extra' item set routine (which is the only one
actually requiring any reset). All other items will be
reinitialized automatically by a new current set value
or upon reallocation when an items compliment changes.
In the <pids> interface, any freeing of dynamic memory
could have been accomplished by adding that 'freefunc'
check to the 'assign' function. However, that requires
an Item_table test with every item. Instead, we'll now
satisfy such needs as the very first step in those set
functions responsible for dynamically acquired memory.
[ the <pids> api retains 2 'cleanup_stack' functions ]
[ to accommodate stack(s) 'reset' & to serve 'unref' ]
Lastly, all the 'itemize_stack' functions were tweaked
by eliminating an unnecessary initialization of result
unions. That objective was already accomplished by the
calloc() in a 'stacks_alloc' function or the remaining
'cleanup_stack' routine found in the <pids> interface.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit standardizes the behavior of the PgUp/PgDn
keys when on the main top display. With PgDn, the last
process will become the first process. With PgUp, that
first task will now appear as the last task displayed.
[ this also eliminates some quirks that were evident ]
[ when paging at or near the end of the process list ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent issue (and merge request) reminded me of gaps
in top's alternate 'vim' navigation keys support. Some
xterm emulators do not pass the customary strings when
keys were used with the <Ctrl> and/or <Alt> modifiers.
While it was a known problem, this issue/merge request
prompted research into the root cause. As it turns out
the problem is traceable to an X resource known by the
name 'eightBitInput'. When 'true' (the default), a key
pressed in combination with <Alt> will not be preceded
by the <Esc> character. Rather, a single character was
presented (modified via an 'eightBitMeta' X resource).
The following approaches would eliminate this problem:
. start xterm thus: xterm -xrm '*eightBitInput: false'
. use: ~/.Xresources with 'Xterm*eightBitInput: false'
. build xterm with 'configure --enable-meta-sends-esc'
( apparently used for CentOS, Fedora, openSUSE, etc. )
. enable xterm's menu via 'configure --enable-toolbar'
( so the user can set the 'Meta Sends Escape' option )
Of course, none of the above steps is desirable from a
user's perspective. So, this patch will add additional
entries to the iokey function's tinfo_tab to represent
strings passed when the <Alt> key does not send <Esc>.
[ hopefully they'll be the same across all platforms ]
Lastly, this patch will also eliminate those redundant
<Atl> + '\', '/', '<' & '>' provisions, which now seem
like overkill and suffer from that same 'eightBitMeta'
xterm problem. And we might as well say goodbye to the
4 '<Alt> + arrow key' table entries (which do not seem
to currently work with any emulator which I can find).
[ what in the world was I thinking way back in 2011? ]
Reference(s):
. issue
https://gitlab.com/procps-ng/procps/issues/135
. merge request
https://gitlab.com/procps-ng/procps/merge_requests/84
Signed-off-by: Jim Warner <james.warner@comcast.net>
These changes are an outgrowth of the research/testing
behind the previous commit. There is no commingling of
select/reap stacks in interfaces beyond the <pids> api
since there's no need to support any 'reset' function.
However, those <pids> changes prompted a review of all
interfaces offering that 'stacks_fetch' function, thus
revealing 2 instances of useless logic/wasted efforts.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the <pids> api was refactored in the commit shown
below, one objective was enabling the simultaneous use
of 'get' & 'select/reap' functions. Unlike other 'get'
functions, this <pids> 'get' acts as an iterator where
successive calls will return successive tasks/threads.
However, that goal wasn't quite met since a stack used
by 'get' was commingled with the 'select/reap' stacks.
Such commingling supported the 'reset' function, again
a provision which was unique to this <pids> interface.
Unfortunately, some poor assumptions in 'stacks_fetch'
produced a SEGV whenever 'reap/select' followed 'get'.
Thus, this patch addresses those issues and guarantees
such commingled stacks (extents) will be accommodated.
Reference(s):
. standardize portions of interface, <PIDS> api
commit 9ebadc1438
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit referenced below addressed (some) anomalies
surrounding 'strv' pointers. However, there remained a
couple quirks involving a potential NULL return value.
Any NULL values returned from the old library readproc
guys would cause no real harm for newlib. But they did
produce the misleading "[ duplicate ENUM_ID ]" result.
The following all represent potential NULL results and
suggest shortcomings in testing of that earlier patch.
. kernel threads do not have cgroup, cmdline & environ
. even if present environ could require root to access
So, this patch reverts a portion of the earlier commit
and ensures when some vectored string is not available
a traditional dash ('-') is the 'strv' returned value.
[ and we'll also correct one typo in the header file ]
Reference(s):
. eliminated a final potential NULL, <PIDS> api
commit 09503dc597
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46
. 01/2019, <stat> origins tweaked
commit 201e816b26
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than offer three separate patches, they've been
consolidated in this single commit. All are related in
that they surfaced while preparing a subsequent patch.
------------------------------------------------------
library: correct a broken '#if define', <SLABINFO> api
It was introduced (embarrassingly) in the patch below.
Reference(s):
commit 97d078a9af
------------------------------------------------------
library: correct a broken 'GET' macro, <DISKSTATS> api
In the patch referenced below, which purported to make
all the 'GET' macros robust, the 'DISKSTATS_GET' macro
was broken. A necessary parameter wasn't passed to the
subsequently invoked function: procps_diskstats_get().
Reference(s):
commit bef8c7fb70
------------------------------------------------------
library: correct a broken 'sort' func, <DISKSTATS> api
In the commit shown below, an attempt to normalize the
errno handling, the sort function inadvertently lost 1
crucial line of code which produces a consistent SEGV.
Reference(s):
commit 06be33b43e
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the patch referenced below traded a compile-time
'sizeof' directive for a run-time 'strlen' call, there
is no need to declare lxc patterns as explicit arrays.
We'll also use the actual lxc patterns by omitting the
beginning slashes ('/') for both of those definitions.
And, looking to the future when most/all lxc users are
using the most recent lxc release, we will make things
slightly more efficient by reversing those two pattern
literals so the most recent pattern was checked first.
Of course, such a change only benefits tasks which are
running in a container. For the majority of processes,
both literals will be compared in that 'if' statement,
assuming the 'LXC' field is currently being displayed.
[ plus, a leftover parenthesis pair has been removed ]
Reference(s):
commit 288d759b8b
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the patch referenced below traded a compile-time
'sizeof' directive for a run-time 'strlen' call, there
is no need to declare lxc patterns as explicit arrays.
We'll also use the actual lxc patterns by omitting the
beginning slashes ('/') for both of those definitions.
And, looking to the future when most/all lxc users are
using the most recent lxc release, we will make things
slightly more efficient by reversing those two pattern
literals so the most recent pattern was checked first.
Of course, such a change only benefits tasks which are
running in a container. For the majority of processes,
both literals will be compared in that 'if' statement,
assuming the 'LXC' field is currently being displayed.
[ plus, a leftover parenthesis pair has been removed ]
Reference(s):
commit f67127e728
Signed-off-by: Jim Warner <james.warner@comcast.net>
As we're using buffered I/O when writing kernel parameters, write errors
may get delayed until we close the `FILE` stream. As we are currently
outputting the key that is to be set disregarding the return value of
`close_stream`, we may end up in a situation where we report error and
success:
$ sysctl kernel.printk_ratelimit=100000000000000
sysctl: setting key "kernel.printk_ratelimit": error code 22
kernel.printk_ratelimit = 100000000000000
Fix the issue by only outputting the updated value in case
`close_stream` does not report an error.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
When writing to procfs via `proc_write` fails, we try to chunk the
buffer into smaller pieces to work around that issue. When searching for
the next location to split the buffer, though, we can underflow the
buffer in case the current offset is smaller than `LINELEN`. Fix the
issue by passing `cookie->offset` instead of `LINELEN` into `memrchr` in
case `cookie->offset` is smaller than `LINELEN`.
This bug can be triggered on musl-based systems, e.g. by executing
$ sysctl kernel.printk_ratelimit=1000000000000000
As the value is out-of-range, `write` will return an error and set
`errno` to `EINVAL`. As we're only trying to write a smallish buffer
with a length smaller than `LINELEN` and as the buffer does not contain
any newlines, the call
token = (char*)memrchr(cookie->buf+offset, '\n', LINELEN);
will underflow the buffer and crash the program.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
