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>
With openSUSE's tumbleweed release of procps-ng-4.0.0,
their source rpm contained a questionable patch. It is
ostensibly devoted to increasing the accuracy for %cpu
calculations in the ps program. However, in my opinion
it goes too far and is quite flawed for these reasons:
1. Six separate files were impacted instead of just 1.
2. While ps was the object, libproc-2 was changed too.
3. A header file's alphabetic item order was violated.
4. The library API and ABI were altered unnecessarily.
It should be noted that all the <pids> TIME items were
made 'real' when representing seconds so that they can
be converted into jiffies/tics if multiplied by hertz.
Thus, there was absolutely no justification for adding
a new PIDS_TICS_ELAPSED ull_int item to the interface.
As an example, assuming a hertz value of 100, there is
enough capacity in all of those 'TIME' seconds to hold
nearly 3 million years worth of tics without a loss of
precision whenever they are changed back into jiffies.
[ that's nine quadrillion seven trillion one hundred ]
[ ninety-nine billion two hundred fifty-four million ]
[ seven hundred forty thousand nine hundred ninety + ]
[ one! or more concisely, as: 9,007,199,254,740,991. ]
So, any need for increased accuracy in that ps program
can be realized within the single output.c file alone.
That's what will be accomplished with this new commit.
And for any doubters here's a 'double' capacity proof:
beg ------ 9007199254740991.000000000000000000000 tic|
d /= 100, 90071992547409.90625000000000000000000 sec
d /= 60, 1501199875790.165039062500000000000000 min
d /= 60, 25019997929.83608245849609375000000000 hrs
d /= 24, 1042499913.743170142173767089843750000 day
d /= 7, 148928559.1061671674251556396484375000 wks
d /= 52, 2864010.752041676081717014312744140625 yrs
d *= 52, 148928559.1061671674251556396484375000 wks
d *= 7, 1042499913.743170142173767089843750000 day
d *= 24, 25019997929.83608245849609375000000000 hrs
d *= 60, 1501199875790.165039062500000000000000 min
d *= 60, 90071992547409.90625000000000000000000 sec
d *= 100, 9007199254740991.000000000000000000000 tic
end ------ 9007199254740991.000000000000000000000 " |
[ who knows, maybe we'll even convince openSUSE that ]
[ the original sledgehammer 'dif' should be dropped. ]
Reference(s):
. openSUSE equivalent: 'procps-ng-4.0.0-accuracy.dif'
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just compliments a change referenced below
by providing the value which includes reaped children.
[ as an aside, it looks like ps only includes reaped ]
[ children values under an obscure BSD or GNU option ]
[ so, this change is possibly of even more relevance ]
Reference(s):
. Mar, 2022 - added %CUU
commit 2ac72e2e80
Signed-off-by: Jim Warner <james.warner@comcast.net>
When %CUU was added, in the commit referenced below, I
stated that 4 similar specifiers already existed. Well
I misspoke since there is actually 5 including 'util'.
Each of those fields had no sort capability. Since the
values are dynamically calculated, they were forced to
use 'PIDS_extra' as the format_array 'sr' designation.
Now each will use 'PIDS_UTILIZATION' and be sort-able.
[ yes, sometimes the calculated values could contain ]
[ reaped children while the sort field does not. but ]
[ such disparity depends on obscure bsd/gnu options. ]
Reference(s):
. Mar, 2022 - added %CUU
commit 2ac72e2e80
Signed-off-by: Jim Warner <james.warner@comcast.net>
This just parallels the top program by adding that new
library PIDS_UTILIZATION item to the ps repertoire. It
should be noted, however, that the new %CUU field is a
little redundant. I mean, ps already has 4 such fields
implemented identified as: '%cpu', 'c', 'cp' & 'pcpu'.
Oh well, at least the newest one offers a little value
added in the form of extra precision. We'll follow the
top lead and display results in the form of: '##.###'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The library refactored 'TIME' items for consistency so
we must adapt to some new data types and calculations.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Not only does that library tweak help to simplify some
top code, but now that ps snprintf fmtstr will finally
be accurate. That is two birdies with a single pebble!
Signed-off-by: Jim Warner <james.warner@comcast.net>
The procfs mount option subset=pid only shows the processes, not things
such as /proc/stat etc.
For certain programs, this should mean they still work, but have reduced
functionality. This is the first cut at some of them.
pgrep - Removed always loading uptime which we never used anyway. The
program now works fine unless we use --older. Add note in man page
stating it will silently fail.
ps - Load boot time and memory total only when required instead of
always. Changed the error messages to something the user actually
cares about "can't get system boot time" vs "create a structure".
Works for most fields except starts and percent memory.
uptime - Give more useful error messages if uptime not available.
vmstat - move header generation after testing for required proc
files, makes the default output more consistent with the rest
of the options.
References:
procps-ng/procps#227https://www.kernel.org/doc/html/latest/filesystems/proc.html#chapter-4-configuring-procfs6814ef2d99
Signed-off-by: Craig Small <csmall@dropbear.xyz>
In that commit referenced below, a new field was added
to the ps program which required adding 2 newlib items
together. Such a need is now satisfied by the library.
So, this commit will just adapt ps for that provision.
Reference(s):
commit e782b1d859
Signed-off-by: Jim Warner <james.warner@comcast.net>
The library added smaps_rollup fields in the referenced commit.
This commit exploits the new fields to give pss and uss options.
These options were first proposed back in 2015 by Petr Malat
and, with the library update, they are finally made it into ps.
Why use proportional or unique segment size? It is argued that
these give a better idea of the "real" memory usage of a process.
References:
commit 12543b6c76
issue #112https://www.freelists.org/post/procps/PSS-and-USS-support-for-pshttps://lwn.net/Articles/230975/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
That snowball, which began as a simple removal of some
brackets, now ends with this third patch restoring the
ability to build our project. It was made necessary by
the renaming (and rearranging) of several enumerators.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Form its inception (back in May of 2011), escaped_copy
has always been a flawed function. It does not operate
on 'escaped' strings but instead treats all input as a
regular string incapable of containing utf8 sequences.
As such, it should only be used for strings guaranteed
to NOT embody multibyte characters (like SUPGIDS). For
all other strings, which could contain utf8 stuff, the
correct function should have been that escape_str guy.
So this commit changes nearly every escaped_copy call.
Reference(s):
. May 2011, original escaped_copy (cmdline, cgroup)
commit 7b0fc19e9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm not sure if anyone actually uses these things, but if you
selected test fields on the command line ps would crash.
$ ps/pscommand -o _left
Signal 11 (SEGV) caught by pscommand (3.3.11.877-0488).
/home/csmall/Projects/procps/procps/ps/.libs/pscommand:ps/display.c:66: please report this bug
Segmentation fault
Anyway, it doesn't now:
$ ps/pscommand -o pid,_left,_left2,_right,_unlimited 1
PID LLLLLLLL L2L2L2L2 RRRRRRRRRRR U
1 tty7 3270/tty4 59:59 [123456789-12345] <defunct>
In that commit referenced below, a promise was made to
revisit an 'escape_str' function in efforts to make it
private to the library. The problem was it's needed by
both ps plus the library which is why it was exported.
So, in an effort to remove it from libprocps.sym, this
patch duplicates all the required code in ps/output.c.
Now, each version can be made private to their caller.
[ along the way we'll use this opportunity to remove ]
[ the 'restrict' qualifiers from function parameters ]
[ while swatting a compiler warning referenced below ]
Reference(s):
. April 2016, most escape functions made private
commit d916d5db86
proc/escape.c: In function `escape_command':
proc/escape.c:182:23: warning: initialization of `const char **' from incompatible pointer type `char **' [-Wincompatible-pointer-types]
182 | const char **lc = (char**)pp->cmdline;
| ^
Signed-off-by: Jim Warner <james.warner@comcast.net>
Before "strlen(outbuf)", if one of the pr_*() functions forgot to do it.
This prevents an out-of-bounds read in strlen(), and an out-of-bounds
write in "outbuf[sz] = '\n'". Another solution would be to replace
strlen() with strnlen(), but this is not used anywhere else in the
code-base and may not exist in all libc's.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
pr_bsdstart(): Replace "strcpy(outbuf," with "snprintf(outbuf, COLWID,"
(which is used in all surrounding functions). (side note: the fact that
many pr_*() functions simply return "snprintf(outbuf, COLWID," justifies
the "amount" checks added to show_one_proc() by the "ps/output.c:
Replace strcpy() with snprintf() in show_one_proc()." patch)
pr_stime(): Check the return value of strftime() (in case of an error,
"the contents of the array are undefined").
help_pr_sig(): Handle the "len < 8" case, otherwise "sig+len-8" may
point outside the sig string.
pr_context(): Handle the empty string case, or else "outbuf[len-1]"
points outside outbuf.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
Signed-off-by: Jim Warner <james.warner@comcast.net>
Enforce a maximum max_rightward of OUTBUF_SIZE-1, because it is used in
constructs such as "snprintf(outbuf, max_rightward+1," (we could remove
the extra check at the beginning of forest_helper() now, but we decided
to leave it, as a precaution and reminder).
The minimum max_rightward check is not strictly needed, because it is
unsigned. However, we decided to add it anyway:
- most of the other variables are signed;
- make it visually clear that this case is properly handled;
- ideally, the minimum max_rightward should be 1, not 0 (to prevent
integer overflows such as "max_rightward-1"), but this might change
the behavior/output of ps, so we decided against it, for now.
Instead, we fixed the only function that overflows if max_rightward is
0. Also, enforce the same safe range for max_leftward, although it is
never used throughout the code-base.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
This strcpy() should normally not overflow outbuf, but names can be
overridden (via -o). Also, check "amount" in all cases.
---------------------------- adapted for newlib branch
. we don't use that 'likely/unlikely' crap in newlib
Signed-off-by: Jim Warner <james.warner@comcast.net>
It is static and not used anywhere.
---------------------------- adapted for newlib branch
. limited to whitespace/formatting differences
Signed-off-by: Jim Warner <james.warner@comcast.net>
We decided not to check the return value of the mprotect() calls,
because they are not vital to the operation of ps.
---------------------------- adapted for newlib branch
. many formatting/whitespace differences
Signed-off-by: Jim Warner <james.warner@comcast.net>
Because there is usually less than OUTBUF_SIZE available at endp.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
. ps no longer deals with the library 'FILL...' flags
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch solves several problems:
1/ Limit the number of characters written (to outbuf) to OUTBUF_SIZE-1
(-1 for the null-terminator).
2/ Always null-terminate outbuf at q.
3/ Move the "rightward" checks *before* the strcpy() calls.
4/ Avoid an integer overflow in these checks (e.g., rightward-4).
May happen if strlen(src) > INT_MAX for example. This patch prevents
escaped_copy() from increasing maxroom and returning -1 (= number of
bytes consumed in dst).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
The SECURE_ESCAPE_ARGS() macro solves several potential problems
(although we found no problematic calls to the escape*() functions in
procps's code-base, but had to thoroughly review every call; and this is
library code):
1/ off-by-one overflows if the size of the destination buffer is 0;
2/ buffer overflows if this size (or "maxroom") is negative;
3/ integer overflows (for example, "*maxcells+1");
4/ always null-terminate the destination buffer (unless its size is 0).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the previous patch concerned an essential change
to avoid dereferencing those NULL pointers, this patch
could be considered optional. For consistency, it just
puts all initialization logic after the setREL macros.
[ plus along the way some inter-function spacing was ]
[ standardized with just a single blank line between ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Under newlib design, ps must loop though all potential
print functions so as to gather the appropriate enum's
while establishing the 'relative' equivalent. The keys
to the setREL/chkREL macros are a NULL 'outbuf' param.
It's imperative that no other functions be called with
that NULL value. Unfortunately, several instances were
found where this was violated. They are now corrected!
Signed-off-by: Jim Warner <james.warner@comcast.net>
These format specifiers are to time & cputime what etimes is to etime.
Signed-off-by: Sébastien Bigaret <sebastien.bigaret@telecom-bretagne.eu>
References:
procps-ng/procps!43
The ps program generally supports multi-byte sequences
in strings representing user and group names. However,
should a multi-byte sequence span the maximum width of
a column, the '+' inserted by ps to signify truncation
will corrupt that sequence, misaligning the text line.
Unfortunately, there's insufficient info returned from
the escape_str function (who calls escape_str_utf8) to
provide a robust response. So, this commit will revert
to the old standby of displaying a number when the '+'
character would've corrupted that multi-byte sequence.
Signed-off-by: Jim Warner <james.warner@comcast.net>
While a Debian bug report referenced below was limited
to the 'eip' and 'esp' fields, this patch also extends
address width adaptations to some other addresses too.
[ and, we do so in a far less invasive manner than a ]
[ redhat approach shown below adding two new fields! ]
Reference(s):
. new debian bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846361
. old redhat solution
https://bugzilla.redhat.com/show_bug.cgi?id=244152
Signed-off-by: Jim Warner <james.warner@comcast.net>
No longer will ps print nwchan as 'ffffff', '-' or '1'
since the proc/PID/stat wchan field didn't represent a
real address anyway. Rather, the field will henceforth
output a dash ('-'), the ps customary 'not available'.
That man document was also tweaked to better represent
actual behavior. An asterisk ('*') was never shown for
threaded tasks and that dash ('-') usually didn't mean
running tasks (sometimes associated with permissions).
Signed-off-by: Jim Warner <james.warner@comcast.net>
dlopen() functionality is only used when SELinux support is enabled, so
<dlfcn.h> only needs to be included when ENABLE_LIBSELINUX is
defined. This fixes the build in configurations where <dlfcn.h> is not
available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch is the response to changes in <pids> types.
These additional modifications were also incorporated.
. ps -------------------------------------------------
pr_wname was eliminated as it just duplicated pr_wchan
pr_wchan referenced WCHAN_ADDR in error, vs WCHAN_NAME
pr_nwchan referenced WCHAN_NAME, not proper WCHAN_ADDR
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch we've completed a progression toward a
standard approach to naming conventions which follows:
* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------
* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------
* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE
[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------
* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------
* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ plus we also play catch up on some earlier changes ]
[ that impacted skill.c, after using --enable-skill! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
