Commit Graph

2358 Commits

Author SHA1 Message Date
Jim Warner
d28f3f28aa top: restore configuration file backward compatibility
The Debian bug referenced below has nothing to do with
locales. In fact, top was made locale independent back
in release 3.3.13 (April, 2018). However, that bug did
reveal some misplaced logic which this patch corrects.

Prompted by the Qualys audit, all rcfile field strings
were checked for potential duplicates which could only
have resulted from some user's manual/malicious edits.

Unfortunately, that code was executed before top had a
chance to enforce the proper/maximum string length (in
the event an extremely old rcfile had just been read).
This created some potential string overrun references.

In top's original 3.3.15 implementation, the potential
overrun extended for 15 characters. That is the number
of field characters added with 3.3.9 (December, 2013).
But, since strchr() was used, no error exit was taken.

In the revised 3.3.16 implementation, the strchr() was
replaced with '&w->rc.fieldscur[n]'. This held overrun
to a single position while producing an error message.

So, this commit just moves that logic to a point where
fieldscur is guaranteed to be longer than EU_MAXPFLGS.

Reference(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951335
. revised 3.3.16 validation logic
commit 775223a817
. original 3.3.15 validation logic
commit 085351a0ee

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-02-18 11:36:04 +11:00
Jim Warner
be31d2470b top: restore one line of code to sig_endpgm() function
When that potential abend at program end was addressed
in the patch shown below, one line of code was removed
in error. That line served to suppress some end-of-job
reports should ATEOJ_RPTSTD or ATEOJ_RPTHSH be active.

So, this patch restores that previously deleted logic.

Reference(s):
. potential SEGV fix, newlib branch
commit 90c22e64ff

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-02-18 11:36:04 +11:00
Jim Warner
1f01bd9a9f ps: for abnormal end allow core dumps (fix qualys bug)
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.

This patch restores expected behavior of those signals
whose default produces a core dump file + termination.

Reference(s):
commit 7bd4f0b6d7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-01-06 09:11:20 +11:00
Jim Warner
1d73eb567c top: at abnormal end allow core dumps (fix qualys bug)
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.

This patch restores expected behavior of those signals
whose default produces a core dump file + termination.

Reference(s):
commit e1f419737f

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-01-06 09:11:20 +11:00
Jim Warner
12b6452135 library: allow negative system DELTA stats, <STAT> api
All TIC delta fields are checked for possible negative
results and set to zero when found. This is done so as
to protect against potential anomalies which depend on
kernel version and/or toggling cpus offline or online.

[ it's probably unnecessary with the latest kernels, ]
[ except for iowait. documentation suggests it might ]
[ decrease which would then create a negative delta. ]

The same approach is employed for most of the 'system'
deltas (ctxt, intr & procs_created). However, with two
of the fields (procs_blocked & procs_running) negative
results were allowed. But it now seems such a division
is unwise so this patch will allow all to go negative.

[ rather than force any 'system' delta value to show ]
[ what's logical, we'll now let all reflect reality. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-01-06 09:11:20 +11:00
Jim Warner
5c37e2d42d library: strictly cosmetic change involving whitespace
This patch just standardizes/normalizes the whitespace
employed within a couple of nearly identical #defines.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-01-06 09:11:20 +11:00
Jim Warner
a331659015 top: reposition some data due to a translation comment
In a translator hint, under a caution, a reference was
made to the "next three items". Unfortunately however,
there was one intervening 'item' to which that caution
did not apply. This commit just relocates that 'item'.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-01-06 09:11:20 +11:00
Craig Small
416b91836a pgrep: check sanity of SC_ARG_MAX
A kernel change means we cannot trust what sysconf(SC_ARG_MAX)
returns. We clamp it so its more than 4096 and less than 128*1024
which is what findutils does.

References:
 procps-ng/procps#152
 https://git.savannah.gnu.org/cgit/findutils.git/tree/lib/buildcmd.c#n535
 https://lwn.net/Articles/727862/
 commit bb96fc4295
2020-01-05 15:19:41 +11:00
Jim Warner
7ef9289ae9 top: update copyright notations & fix a man page error
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 4550e60144

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-10-27 22:27:49 +11:00
Jim Warner
8174a5c8b7 top: whack insidious bug surrounding auto-sized fields
This patch will eliminate a bug which is unique to our
newlib branch. It's extremely rare and only happens if
a search ('L'/'&') is initiated during the period when
fields are currently being auto-sized (AUTOX_MODE on).

This bug surfaces as either all zero results for tasks
displayed or a segmentation fault, depending upon what
fields were activated. It is caused by the timing of a
call to the <pids> 'reset' function. When called after
a task refresh, but before do_key(), this bug appears.

So this patch just ensures that 'reset' will be called
after do_key() & before the tasks have been refreshed.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-10-27 22:27:49 +11:00
Jim Warner
11cf6cc005 library: removed that 'calloc/free' cruft where doable
Under newlib, the only caller of the readproc routines
is that pids module. And in every case, the address of
some static proc_t structure has always been provided.

As a result, there is no need for the logic supporting
calloc() for a possible NULL pointer which was present
in both of those readproc() and readeither() routines.

Additionally, that pids module takes ownership of most
dynamically acquired 'str' plus 'strv' memory whenever
assigning to a results structure. So, henceforth under
the free_acquired() guy we will only free those string
fields which might exist when not explicitly selected.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-10-27 22:27:49 +11:00
Jim Warner
281c37d1cd library: removed that 'simple_readtask' unused pointer
This patch just eliminates a parameter present for the
simple_readtask() function which is not needed nor has
it ever actually been used. It will make calls to that
function (via taskreader ptr) slightly more efficient.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-10-27 22:27:49 +11:00
Jim Warner
b5587b7b94 library: removed that 'did_fake' flag from the PROCTAB
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>
2019-10-27 22:27:49 +11:00
Jim Warner
97f7c7a549 library: removed that 'SIGNAL_STRING' conditional code
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>
2019-10-27 22:27:49 +11:00
Jim Warner
11df806a7c library: correct one reference typo in that <PIDS> api
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>
2019-10-27 22:27:49 +11:00
Jim Warner
e7995652be NEWS: update/catch up with the 'master' branch version
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>
2019-09-22 07:32:03 +10:00
Jim Warner
3caa7079d6 docs: use correct units in free.1 _________ (catch up)
Reference(s):
. origina master branch commit, 5/31/18
commit c51b329a32

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-09-22 07:32:03 +10:00
Jim Warner
3860f39b3e ps: increase command name length to 64 ____ (catch up)
Reference(s):
. orginal master branch commit, 5/19/18
commit 14005a371e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-09-22 07:32:03 +10:00
Jim Warner
34a5ea71cd top: parallel the master branch pids monitoring change
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>
2019-09-22 07:32:03 +10:00
Jim Warner
90c22e64ff top: avoid a potential SEGV during program termination
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>
2019-09-22 07:32:03 +10:00
Jim Warner
33cd2ccf87 top: tweak logic associated with keyboard translations
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>
2019-09-22 07:32:03 +10:00
Clay Baenziger
e516cf4a18 testsuite: pgrep: Provide test for matching a more than 4k command line; beware as TCL does not seem to match on strings >4k 2019-09-21 17:00:53 +10:00
Craig Small
61b627d53c pgrep: Use POSIX _SC_ARG_MAX for maximum full command line length
Modified for newlib but based upon patch in master by
Clay Baenziger <cwb@clayb.net>

References:
    commit f9e56d3c66
    procps-ng/procps!85
2019-09-21 16:58:30 +10:00
Craig Small
012db8222e pidof: Fix separator option
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 73492b182d
    procps-ng/procps#141
2019-09-21 16:20:41 +10:00
Craig Small
52f112d255 watch: fix unsetting of COLOR flag
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
2019-09-21 16:05:13 +10:00
Craig Small
a6c0795d49 sysctl: ignore errors from lines starting with -
The systemd sysctl ignores errors from preload files that start
with a hyphen.  This change brings the procps sysctl into line with
their change.

References:
    procps-ng/procps#138
    https://github.com/systemd/systemd/pull/13191
    https://github.com/systemd/systemd/pull/13141
2019-09-21 15:53:45 +10:00
Jim Warner
97e1264525 top: standardize PgUp/PgDn management within task area
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>
2019-07-04 20:46:18 +10:00
Jim Warner
e6a2931c39 top: attempt to provide missing xterm vim keys support
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>
2019-07-04 20:46:18 +10:00
Jim Warner
1d8d4be046 library: add a 'CPU_ZEROTICS' equivalent to <STAT> api
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>
2019-07-04 20:46:18 +10:00
Jim Warner
40883a0b85 library: minimize the use of 'cleanup_stacks' routines
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>
2019-07-04 20:46:18 +10:00
Jim Warner
22a3bcbd6d library: remove useless code for 2 'stacks_fetch' guys
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>
2019-05-16 21:23:06 +10:00
Jim Warner
f87fc7dc83 library: tweak support for get/select/reap, <PIDS> api
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>
2019-05-16 21:23:06 +10:00
Jim Warner
a9bfb186eb library: correct 'vectorized' string logic, <PIDS> api
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>
2019-05-16 21:23:06 +10:00
Jim Warner
30e27d48e9 misc: adapted programs impacted by header file changes
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-26 19:55:30 +11:00
Jim Warner
6671a3a8b7 library: refactored some header file items and origins
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>
2019-03-26 19:55:30 +11:00
Jim Warner
47af06b52b library: repair any broken stuff found during refactor
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>
2019-03-26 19:55:30 +11:00
Jim Warner
32f93b56b7 library: tweak that lxc container support a final time
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>
2019-03-26 19:55:30 +11:00
Jim Warner
a4da552d4e library: eliminate an unnecessary #include, <STAT> api
That patch shown below should have also included this.

Reference(s):
commit 68d7f7a673

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-26 19:55:30 +11:00
Jim Warner
e85e3ee4d8 top: just correct a couple of misspellings in comments
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-26 19:55:30 +11:00
ed
7b4ad698cc pgrep.c: Match based on process run state for issue 109
References:
 procps-ng/procps#109
2019-03-20 20:59:00 +11:00
Patrick Steinhardt
866a27cdcd sysctl: do not report set key in case close_stream fails
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>
2019-03-04 21:55:24 +11:00
Patrick Steinhardt
09a3687547 procio: fix potential out-of-bounds access when write fails
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>
2019-03-04 21:55:07 +11:00
Patrick Steinhardt
70ed1a72ad procio: use the user-supplied delimiter to split large input
The `fprocopen` function allows users to specify a delimiter chacter
that is used to split very large input lines into smaller chunks. While
the code checks that the caller did actually supply the delimiter, it is
in fact never used to split the string. Instead, the hardcoded default
character ',' is always used to split the string.

Fix the issue by using `cookie->delim` instead.
2019-03-04 21:54:43 +11:00
Patrick Steinhardt
2552b97afd docs: fix "delimeter" typo in fprocopen man page 2019-03-04 21:54:24 +11:00
Jim Warner
34ca0a17ec top: adapt for changes in item identifiers, <STAT> api
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-22 22:49:24 +11:00
Jim Warner
201e816b26 library: improve header file item comments, <STAT> api
This patch just polishes the 'origin' comments for the
<STAT> header file. In particular those derived/unique
items (the 'SUM' guys) will now be properly explained.

[ in order to employ the 'derived from above' phrase ]
[ with their DELTA versions, all SUM items had to be ]
[ relocated (and some renamed). in turn, that had an ]
[ impact on many portions of the .c source file too. ]

Reference(s):
. summary calculations introduced
commit 2c86c4984a
. origins added to header files
commit 96d59cbf46

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-22 22:49:24 +11:00
Jim Warner
68d7f7a673 library: remove one needless function call, <STAT> api
This small change is an outgrowth of the research into
the bug represented by that merge request shown below.

With the master branch, a real buglet was subsequently
addressed. In this newlib branch, no bug existed since
the <stat> API relies solely on just cpus reflected in
(and parsed from) the kernel's /proc/stat pseudo file.

[ since that procps_stat_new() priming read about to ]
[ be performed will value info->cpus.total, there is ]
[ no need to separately invoke a procps_cpu_count(). ]

Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/82

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-22 22:49:24 +11:00
Jim Warner
288d759b8b library: adapt readproc for the latest lxc conventions
The merge request shown below prompted (thankfully) an
examination of our lxc containers logic in readproc.c.

As it turns out, the lxc folks changed that eyecatcher
used to identify containers within a task cgroup file.

So this patch, with little extra cost, will enable the
libprocps lxc_containers() guy to handle both strings.

[ additionally, I was shocked to find lxc allows the ]
[ eyecatcher to be changed at ./configure time. such ]
[ a provision has always existed. unfortunately, the ]
[ changed value was only available to root, assuming ]
[ one wished to tackle that undocumented liblxc api. ]

Reference(s):
. what prompted lxc support reevaluation
https://gitlab.com/procps-ng/procps/merge_requests/82
. original lxc support introduced
commit 0557504f9c

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-22 22:49:24 +11:00
Jim Warner
96d59cbf46 library: add item origin (as comments) to header files
A lack of documentation seems to be the major obstacle
to releasing this new library. So, in an effort to get
the ball rolling again, this patch adds the origins of
each item as a comment to six of the new header files.

However, before reviewing how such changes may benefit
that documentation objective, it seemed appropriate to
first reflect on newlib's background & current status.

___________________________________________ BACKGROUND
Discussions about and work on a new library began back
in July 2012 but quickly died. After a lull of 2 years
those discussions were resumed in August 2014 but soon
died also (and no code survived the gitorious demise).

With those early discussions, the recommended approach
was to encapsulate all of the libprocps data offerings
in individual functions. When it came to extensibility
it was suggested we should rely on symbols versioning.

Unfortunately that approach would have made for a huge
Application Programming Interface virtually impossible
to master or even document. And, runtime call overhead
would have been substantial for ps and especially top.

So, an alternative design was sought but there were no
new suggestions/contributions via freelists or gitlab.
Thus, in spite of a lack of library design experience,
the procps-ng team (Craig & Jim) set out to develop an
alternative API, more concise and with lower overhead.

Reference(s):
. 07/01/2012, begin library design discussion
https://www.freelists.org/post/procps/Old-library-calls
. 08/12/2014, revival of library design discussion
https://www.freelists.org/post/procps/libprocs-redesign

_____________________________________ DESIGN EVOLUTION
Our newlib branch first appeared on June 14, 2015. And
our current API actually represents the 4th generation
during the past 3 years of evolution. First, there was
a basic 'new', 'get' and 'unref' approach, using enums
to minimize the proliferation of 'get' function calls.

Then, in anticipation of other programs like ps, where
multiple fields times multiple processes would greatly
increase the number of 'get' function calls, a concept
of 'chains' was introduced. This became generation #2.

Such 'chains' proved unnecessarily complex so 'stacks'
replaced them. This was considered the 3rd generation,
but too many implementation details were still exposed
requiring those users to 'alloc', 'read', 'fill', etc.

Finally, a 4th generation emerged representing several
refinements to standardize and minimize those exported
functions, thus hiding all implementation details from
the users. Lastly, handling of 'errno' was normalized.

Reference(s):
. 06/14/2015, revival of new API discussion
https://www.freelists.org/post/procps/The-library-API-again
. 06/24/2015, birth of the newlib branch
https://www.freelists.org/post/procps/new-library
. 06/29/2015, 2nd generation introduced 'chains'
https://www.freelists.org/post/procps/new-library,8
. 07/22/2015, 3rd generation introduced 'stacks'
https://www.freelists.org/post/procps/newlib-stacks-vs-chains
. 06/18/2016, 4th generation refinements begin
https://www.freelists.org/post/procps/newlib-generation-35
. 11/10/2017, 4th generation standardized 'errno'
https://www.freelists.org/post/procps/some-more-master-newlib-stuff

_______________________________________ CURRENT DESIGN
Central to this new design is a simple 'result' struct
reflecting an item plus its value (thanks to a union).
As a user option, these item structures can be grouped
into 'stacks', yielding many results with just 1 call.
Such a 'stack' can be seen as a variable length record
whose content/order is determined solely by the users.

Within that 'result' structure, the union has standard
C language types so there is never a doubt how a value
should be used in a printf statement. Given that linux
requires a least a 32-bit platform the only difference
in capacity surrounds 'long' integers. And, where such
types might be used, the 32-bit maximums are adequate.

The items themselves are simply enumerators defined in
the respective header files. A user can name any items
of interest then the library magically provides result
structure(s). The approach was proven to be extensible
without breaking the ABI (in commit referenced below).

The 6 major APIs each provide for the following calls:
. 'new' ---------> always required as the first call .
. 'ref' -------------------------> strictly optional .
. 'unref' --------> optional, if ill-behaved program .
. 'get' --------------------> retrieve a single item .
. 'select' ----------------> retrieve multiple items .

And the 'get' and 'select' functions provide for delta
results representing the difference between successive
get/select calls (or a 'new' then  'get/select' call).

For the <diskstats>, <pids>, <slabinfo> & <stat> APIs,
where results are unpredictable, a 'reap' function can
return multiple result structures for multiple stacks.

The <pids> API differs from others in that those items
of interest must be provided at 'new' or 'reset' time,
a function unique to this API. And the <pids> 'select'
function requires PIDs or UIDs which are to be fetched
which then operates as a subset of 'reap'. Lastly, the
'get' function is an iterator for successive PIDs/TIDs
returning items previously identified via 'new/reset'.

To provide assistance to users during development, the
special header 'proc/xtra-procps-debug.h' is available
to check type usage against library expectations. That
check is activated by including this header explicitly
or via build using: ./configure '-DXTRA_PROCPS_DEBUG'.

Reference(s):
. 08/05/2016, type validation introduced
https://www.freelists.org/post/procps/newlib-types-validation
commit e3270d463d
. 08/11/2016, extensibility while preserving ABI example
https://www.freelists.org/post/procps/new-meminfo-fields
commit 09e1886c9e

_________________________ INITIAL DOCUMENTATION EFFORT
The initial attempt, referenced below, dealt primarily
with the <pids> interface. Separate man pages for each
exported function were created. Plus there was another
document describing the items, among other miscellany.

Adopting such an approach encounters several problems:

1. In order to use these man pages, users are required
to already know how to use the library. Or alternately
one could randomly search each of them while trying to
ascertain which function call satisfies their need and
what exactly was the proper compliment/order required.

2. While we can explain what all of those <pids> items
represent, that certainly isn't true for all the APIs.
See the gaps in kernel documentation for <meminfo> and
complete lack of documentation with that <vmstat> API.

3. Our documentation effort should take pains to avoid
unnecessary implementation details. Here's an example:
. "The pointer to info will have memory"
. "allocated and a structure created."

Alternatively, the following conveys user requirements
while not offering any internal implementation detail:
. "You must provide the address of a NULL"
. "info structure pointer."

Reference(s):
. 01/04/2017, initial documentation offering
https://www.freelists.org/post/procps/Using-reap-and-get
commit 2598e9f2ce

___________________ RECOMMENDED DOCUMENTATION APPROACH
I recommend that the newlib documentation consist of 3
man pages only. The first would cover the 5 major APIs
and their common functions. The second would deal with
the <pids> API exclusively, explaining how it differs.
Any remaining exported libproc functions which are yet
to be included could be represented in a 3rd document.

For these new documents the following are are assumed:

1. Since we will not be able to document all items, we
shouldn't try to document any items. We should instead
rely on proc(5) or Documentation/filesystems/proc.txt.

2. Program development often involves referencing some
header file(s). So, make that an absolute requirement.

3. With the addition of item origins, represented with
this commit, and considering that 'types' were already
present, the header file might be all some users need.

4. And who knows, when a user of our libproc complains
about gaps in their documentation, it might prompt the
kernel folks to correct those long standing omissions.

To summarize, I suggest that we replace that libproc.3
document with a more general one explaining the basics
of accessing this new library and the common calls for
most of the major interfaces. We can then create a new
document (libproc-pids.3?), which explains differences
in using the <PIDS> application programming interface.
A final document (libproc-misc.3?) covers what's left.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-03 08:06:48 +11:00
Jim Warner
d9f88246f6 library: insert 'PIDS_ID_TID' for symmetry, <PIDS> api
This change is being made in anticipation of adding the
source origin of each item to the <pids.h> header file.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-03 08:06:48 +11:00