Shell kill would report a problem if you tried to kill a process
while procps kill was silent. This meant it looked like kill worked
when it actually failed.
References:
commit 07642b8ea6https://bugs.debian.org/733172
With the change to struct pids_fetch, we'll just trade
some dot ('.') code for some pointer to ('->') syntax.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With all our 3rd generation interfaces, we're now well
positioned to preserve binary compatibility should new
fields be added to any public structure (assuming that
the 'result' union already contains its largest type).
This remains true even for the <pids> interface, which
unlike the others, has one structure embedded within a
separate struct rather than declaring a pointer to it.
The counts struct was positioned after the stacks ptrs
array so as to preserve that ABI if ever new ints were
added. Logically, however, the counts (especially that
total) should precede the stacks array if we wished to
properly place a horse (total) before a cart (stacks).
So to enable relocating those counts we will no longer
embed that structure, but provide a pointer to it. And
this will make accessing syntax feel more natural too.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch represents the partial revert of the commit
referenced below. And, so that yours truly (the author
for goodness sake) doesn't shoot his tootsies again in
the future, a cautionary programmer comment was added.
Reference(s):
commit dea4033418
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch represents the following minor adjustments:
. old PROCTAB used with select & reap more descriptive
. reformatted PROCPS_PIDS_VAL macro like other 3rd gen
Signed-off-by: Jim Warner <james.warner@comcast.net>
The following commit message is shared with 4 patches.
------------------------------------------------------
Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.
That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.
This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.
The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.
[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The following commit message is shared with 4 patches.
------------------------------------------------------
Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.
That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.
This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.
The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.
[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The following commit message is shared with 4 patches.
------------------------------------------------------
Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.
That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.
This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.
The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.
[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The following commit message is shared with 4 patches.
------------------------------------------------------
Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.
That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.
This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.
The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.
[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
All our numa logic was well encapsulated under #ifndef
NUMA_DISABLE (as ./configure --disable-numa), with the
exception of 1 case label. The reason it didn't create
any problems is because the sole consumer (top) itself
responded to the presence of #define NUMA_DISABLE too.
But if that option wasn't used, an oops still awaited.
When experimenting with a 32-bit library plus a 64-bit
kernel, a bug was revealed should the numa library not
have been found. Our 'reap' function must tolerate the
potential of a 0 return from that stacks_fetch_tics().
Now, if numa is desired but not possible, we'll be ok.
[ and, we'll build numa history from fresher sources ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
On MacOS the system already has user_from_uid and group_from_gid.
These are renamed pwcache_get_user and pwcache_get_group.
They were also exported but did not appear in the symbol file
or used by any of the procps binaries. They are no longer exported.
References:
https://gitlab.com/procps-ng/procps/issues/34
Signed-off-by: Craig Small <csmall@enc.com.au>
This patch contains the following collection of stuff:
. an identifier Pids_read is now Pids_reap like <stat>
. eliminate redundant param from the <stat> VAL macros
. eliminate the unneeded tailored <stat> SUM_VAL macro
. corrected comment spelling for 'gouped' to 'grouped'
Signed-off-by: Jim Warner <james.warner@comcast.net>
When those items were made dynamic at 'new' time, some
other functions, previously assured of their presence,
failed to verify a 'reset' had acually been requested.
This commit just corrects that oversight and avoids an
attempt to 'assign_results' when no items are present.
Reference(s):
. when items/numitems became optional
commit 9ebadc1438
Signed-off-by: Jim Warner <james.warner@comcast.net>
This development (only) define can be used to turn top
into a simple text program, disabling termcap effects.
But input (at screen bottom) suffers from a line wrap.
So, this commit just makes the input prompt processing
a little more effective by adding one leading newline.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.
<meminfo> ............................................
. eliminated duplicate decl of 'struct procps_meminfo'
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. how did i miss relocating all these friggin' #undefs
. cleanup 'get' return logic (remove a redundant 'if')
<pids> ...............................................
. repositioned the procps_pidsinfo structure in header
. removed the extra trailing comma from enum pids_item
. standardized/normalized results struct union members
<slabinfo> ...........................................
. corrected comment typo (jeeze, in an 'aligned' para)
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. removed an obsolete #undef from procps_slabinfo_sort
. cleanup 'get' return logic (remove a redundant 'if')
<stat> ...............................................
. how did i miss relocating all these friggin' #undefs
. corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix
. removed the extra trailing comma from enum stat_item
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. strengthen those parm checks in procps_stat_get func
. cleanup 'get' return logic (remove a redundant 'if')
<vmstat> .............................................
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. cleanup 'get' return logic (remove a redundant 'if')
[ virtually all of these tweaks reflect the author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When experimenting with two macro constants for stat.c
(#define STACKS_INCR & #define NEWOLD_INCR), a bug was
revealed in top, only surfacing if both were set to 1.
At those settings an absolute minimum number of stacks
would be allocated for CPUs & numa NODEs. This in turn
led top to overrun the lessor number of nodes since he
used the cpu index when accessing those numa stack(s).
What he should have been accessing was the cpu stacks.
Signed-off-by: Jim Warner <james.warner@comcast.net>
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the dust now settling on all those 3rd generation
upgrades, this patch tries to provide some consistency
among the separate modules involved. Someday we should
consider a 4th generation where all redundant code has
been removed and isolated in a new shared source file.
Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.
<meminfo> ............................................
. strictly formatting/comment changes, code unaffected
<pids> ...............................................
. replaced a local mkSTR macro with existing STRINGIFY
. added fetch narrative explaining duplicate addresses
<slabinfo> ...........................................
. rearranged some free logic for procps_slabinfo_unref
. added fetch narrative explaining duplicate addresses
<stat> ...............................................
. added #define ENFORCE_LOGICAL, just as in <slabinfo>
. replaced a local mkSTR macro with existing STRINGIFY
. alphabetized the function declarations in the header
<vmstat> .............................................
. made one coverity concession with read_vmstat_failed
[ several of these changes may reflect this author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'procps.h' header includes all other headers which
contain exported (public) functions, while this header
has some (private) macros required for implementation.
If we mix the two, by including procps.h in this file,
we'll lose all hope of the compiler catching the kinds
of errors corrected in an immediately preceding patch.
[ we must be diligent, always constantly striving to ]
[ protect jimmy from ill effects due to copy & paste ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Needless to say, when one copies and then pastes, it's
always better when those results are refined somewhat.
The qsort callback declarations used the wrong results
type and 2 of their 3 input parameters were wrong too.
So this patch will fix that & generalize declarations.
[ plus add comment guidance about noop & extra enums ]
[ & provide for 'noop' sorting, as is done in <PIDS> ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Though all those callback's parameters are ignored and
qsort treats them as pointers to void, it's wrong when
3rd parm is 'enum pids_item', not 'struct sort_parms'.
So we will fix it in a way that lessens the likelihood
of another such a mistake when some new type is added.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When our <SLABINFO> was recently re-designed, the sort
callback functions became table driven, whereas before
a single callback used switch/case constructs based on
an 'item'. Thus, sorting was made a tad more efficient
but, it introduced a buglet into that slabtop program.
The root cause of this bug was the fact that the field
NAME required a low-to-high sort and all other slabtop
fields used high-to-low. Fortunately, along with those
<SLABINFO> table driven sort changes, that i/f offered
users the option of either low-to-high or high-to-low.
So this patch just exploits that choice. And, it means
that such responsibilities are now properly located in
calling code, not in what's a general purpose library.
Reference(s):
. most recent lib sort enhancement & breakage
commit 5d5a52a380
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the decision was made to also add that Linux-4.5
support (was only in this newlib branch) to our master
branch, a tweak to newlib's top is necessary. In order
to share the rcfile between them, any fields unique to
a branch must appear last in it's list of enumerators.
And the troublesome field in question above is CGNAME.
It doesn't matter if a unique field is on or off, only
that it, as a higher enum/char, appear after all other
shared fields. Otherwise one risks the 'corrupt' error
message from the top without that field or the display
of the wrong column in the top with that unique field.
[ and strictly speaking, the changes under top_nls.c ]
[ were technically not really necessary. however, we ]
[ choose to maintain strict ordering via enum value. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit simply tries to keep naming plus formating
conventions on a par with the continuing climb up that
learning curve. These changes were suggested following
<slabinfo> sources upgrade from 2nd to 3rd generation.
Signed-off-by: Jim Warner <james.warner@comcast.net>
After normalizing the <SLABINFO> module, much of which
was based on this module, a structure which is crucial
to concurrent select/reap support is renamed the same.
Such a need for concurrent support was revealed during
slabtop testing. That program requests (select) global
data after calling for individual node data (reap) but
before those stacks have been accessed. Therefore, one
set of 'items'/'extents' could not possibly be shared.
So now we will know the former struct fetch_support as
ext_support. The former name was potentially confusing
since the struct was used by both 'select' and 'reap'.
However, only 'reap' ever called the 'fetch' function.
[ this <STAT> already accommodated concurrent usage. ]
[ in fact it contains 3 separate sets of items/exts. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Oops, the PROCPS_VMSTAT_logical_end enum reflected the
source state before all those DELTA enum's were added.
[ plus add a couple of overlooked #undef directives, ]
[ and whack an unneeded stacks_alloc assignment too! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch was prompted through work on the <slabinfo>
upgrade from 2nd gen to 3rd. And while this assignment
caused no real harm, it most certainly was misleading.
[ plus add a couple of overlooked #undef directives! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Before this major redesign, the slabs interface likely
was our messiest 2nd generation attempt at opaqueness.
Beyond the standard 'new', 'ref' & 'unref', there were
a total of 12 exported functions. Now, there are four.
The 1st step was to remove several of those functions.
These were quick to go since they were not used (yet):
. procps_slabnode_count
. procps_slabnode_getname
. procps_slabnode_getstack
Then, the following were internalized so users needn't
be burdened with implementation details in the future:
. procps_slabinfo_read (renamed: read_slabinfo_failed)
. procps_slabnode_stacks_alloc (renamed: stacks_alloc)
Still others evolved into the minimal interface we had
strived for in the other upgraded 3rd generation APIs:
. procps_slabnode_get -----------> procps_slabinfo_get
. separate stack_alloc/fill --> procps_slabinfo_select
. separate stacks_alloc/fill ---> procps_slabinfo_reap
. procps_slabnode_stacks_sort --> procps_slabinfo_sort
------------------------------------------------------
Beyond those reductions, the major modifications were:
. This API tries to be as forgiving as possible and as
such won't throw errors when a caller request makes no
sense. For example, if a 'get' or 'select' requested a
SLABNODE item (with no current means to id that node),
results will be zero. By the same token, should 'reap'
include a global SLABS item (meaning those values will
be duplicated in *every* node stack) it'll be allowed.
. If the above behavior is undesired, a new #define of
ENFORCE_LOGICAL can be used to restrict certain items.
. Permission problems will now be caught at 'new' time
thanks to a priming 'read' call. That read also serves
to make DELTA values potentially useful at 1st access.
. Separate slab/slabnode enumerators were consolidated
into one, simplifying validation & the results struct.
. Several internal parameter checks were relaxed since
they were already checked by the caller. Besides if we
cannot trust our own code we might as well hang it up.
. That sort provision was made more efficient and will
offer the ascending choice, in addition to descending.
------------------------------------------------------
Lastly, some additional thoughts regarding the future:
. It would not be difficult to expand 'select' to also
accept a nodeid, or to clone it as 'select_node'. And,
should the same be extended to 'get', a results struct
could be returned instead of signed long accommodating
the extra data type(s) like a node name (string data).
. The 'get' function is not currently affected by that
define ENFORCE_LOGICAL. However, at some future point
perhaps -EINVAL would be more appropriate than a zero.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.
This patch brings slab into line with such a standard.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The original test did not NULL the unallocated info pointer. This
was incorrectly calling the procps_pids_new() function.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
This commit just eliminates all the procps_vmstat_read
calls since the interface now handles that requirement
as needed when the 'get' and 'select' guys are called.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This interface represented a 2nd generation attempt at
the opaque newlib approach. In other words, it did not
involve the 1st generation 'chains'. Instead, 'stacks'
were employed. But the interface wasn't user friendly.
Users were required to create their own stacks, before
calling 'getstack' to retrieve multiple results with a
single call. Even worse, sometimes 'read' was required
before calling 'get' when working with single results.
So this commit represents the 3rd generation approach.
We eliminate the burden of 'read' and creating stacks.
Rather, beyond those standard 'new', 'ref' and 'unref'
functions, we'll offer just 'get' (single result) plus
a 'select' function (for multiple results in 1 stack).
And along the way, this commit vastly expands the data
extracted from /proc/vmstat. All values that currently
exist (and their delta equivalents) are now available.
Deltas were included for everything because there's no
real runtime costs beyond using a little extra memory.
The only problem is a lack of documentation for all of
those fields, as is reflected in the references below.
Oh well, maybe someday someone will dig through kernel
sources & finally plug that rather large document gap.
[ as an aside, rather than using a 'strcmp' approach ]
[ when parsing the /proc/vmstat file, as is found in ]
[ the <meminfo> module, we exploit those hash search ]
[ provisions that are found in the <search.h> header ]
Reference(s):
http://www.spinics.net/lists/linux-man/msg09096.htmlhttp://www.linuxinsight.com/proc_vmstat.html
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch represents the following minor adjustments:
. the official PROCPS_MEMINFO_VAL macro has become the
basis for our own abbreviated MEM_VAL derivative macro
just like was done for all the other newlib interfaces
. it felt like time to change those forest_?? function
names while maintaining their special relationships to
one another (alphabetic, with each 1 longer than prev)
. and some whitespace was altered and some lines added
Signed-off-by: Jim Warner <james.warner@comcast.net>
With an eye to the future, rather than managing a long
switch/case construct in the procps_stat_get function,
we'll adopt the approach used in the <meminfo> module.
By making 'get' processing table driven too, just like
'select' is already, that may ease future maintenance.
Along the way a rather large boo-boo was fixed dealing
with that /proc/stat 'procs_running' field which crept
in with the commit referenced below. It wasn't spelled
correctly and thus was never captured as PROC_RUNNING.
Reference(s):
commit abc71a46ad
Signed-off-by: Jim Warner <james.warner@comcast.net>
When this interface was normalized/standardized, under
the commit referenced below, the parameters were never
validated in the 'get' function. Let's plug that hole.
Reference(s):
commit 407f1b71de
Signed-off-by: Jim Warner <james.warner@comcast.net>
Update the pids tests for tweaked API. Unsure why the toomany
test doesn't work, may point to a problem in the change as it used
to trigger, or the library has flexibility.
In that reference below a specific systemd problem was
fixed in the commit shown. However lurking deep within
the <pids> interface was yet one final case where NULL
could be returned, involving 'strv' and the following:
. a user requested both a single string vector (always
returned as a normal string) & the vectorized version,
as with PROCPS_PIDS_CMDLINE and PROCPS_PIDS_CMDLINE_V.
. a user simply duplicated some vectorized enum items.
The root of that NULL problem is the fact those single
string vectors shared the same proc_t field with their
true vectorized version. So while multiple occurrences
for most strings could be satisfied with strdup versus
the normal ownership usurpation, those true vectorized
fields could not be quite so easily copied/duplicated.
Thus newlib chose to return a NULL result.strv pointer
under either of the above scenarios (which perhaps was
just a user boo-boo in the first place). In any event,
the NULL was a potential for true string vectors only.
Now, since newlib is the sole caller into the readproc
module, separate fields have been created for what are
just normal strings (never vectorized) and those which
remain the true vectorized versions. And, former flags
which only worked if combined, now act as stand alone.
Thus, both PROCPS_PIDS_CMDLINE & PROCPS_PIDS_CMDLINE_V
can be used simultaneously (as they should have been).
Also with this patch, items which a user duplicates in
the stack (beyond the first such item) will return the
the string "[ duplicate ENUM_ID ]". This practice will
apply to both single strings and true vectorized ones.
In addition to informing users of their error, it will
also mean potential NULLs need now never be a concern.
Reference(s);
http://www.freelists.org/post/procps/systemd-binary-vs-library
commit 0580a7b4c6
Signed-off-by: Jim Warner <james.warner@comcast.net>
Calls to free() have now been reintroduce in the new()
function to quiet coverity warnings. Those free's were
removed originally as that library 'new' was returning
with a fatal error and a caller should end abnormally.
Plus, it is virtually impossible to fail a malloc call
under linux. And lastly, they required braces with the
if statement making the code considerably less pretty.
[ commit also includes 2 unrelated whitespace tweaks ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
A potential conflict arises should should some program
attempt to access systemd data using our library built
without that support (--disable-systemd). And while we
could argue that all callers should check against NULL
string pointers, it's not expected of libprocps users.
So we'll guarantee 'em valid string consisting of "?".
Reference(s):
http://www.freelists.org/post/procps/systemd-binary-vs-library
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the API changed for the use_format the type changed for the
system variables out of stat, but the printf format was not changed
along with it.
vmstat.c:868:14: warning: format ‘%lld’ expects argument of type ‘long
long int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
printf(_("%13lld interrupts\n"), SYSv(sstat_INT));
References:
commit 2e6435a39d
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The patch referenced below silenced an 'uninitialized'
compiler warning but it also created a bug where zeros
appeared under the Address column with that -x option.
So this commit swats that bug and avoids any warnings.
[ while yours truly created that bug, in his defense ]
[ let's at least acknowledge the god awful loop code ]
[ which was the root of the problem & wrong solution ]
[ so the ugliness of this most recent solution is in ]
[ perfect harmony with the *really* ugly loop itself ]
Reference(s):
commit 0299bd15b0
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than adopt an approach offered below, involving
changing all enumerator names to convey types, perhaps
this much more modest change is a worthwhile 1st step.
By just changing the comments to 'right justification'
it dramatically improves readability, at least it does
to my eye. Perhaps such an approach can postpone that
massive alternative effort for the foreseeable future.
Reference(s):
http://www.freelists.org/post/procps/newlib-drip-drip,4
Signed-off-by: Jim Warner <james.warner@comcast.net>
