Commit Graph

2044 Commits

Author SHA1 Message Date
Jim Warner
4da0030544 NEWS: add issue and bugzilla references where possible
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-08-19 20:52:41 +10:00
Jan Rybar
62da5ee3ce top: refresh interval accepts non-locale decimal value
For the past 3 years top has fully honored that locale
LC_NUMERIC setting which impacts his refresh interval.
For the past nearly 5 years top has saved that refresh
value in a locale independent form in his config file.

With this commit we'll intentionally break top so that
a comma or period will be accepted for the radix point
regardless of what that LC_NUMERIC may have suggested.

The current locale LC_NUMERIC will, however, determine
how the delay interval is displayed in the 'd' prompt.

[ This position is better than the approach employed ]
[ by those coreutils 'sleep' and 'timeout' programs. ]
[ Both claim to permit floating point arguments. But ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]

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

Prototyped by: Jan Rybar <jrybar@redhat.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-08-19 20:46:39 +10:00
Jim Warner
bb19ac0926 top: at program startup, avoid a little extra overhead
There was a time when the PROCPS_PIDS_noop represented
the highest valued enumerator. Therefore if one wished
to prime an array consisting of pids_result structures
with this specific item a loop would have been needed.

Now that this enum is the first one, with the value of
zero, we can avoid avoid such a loop with just calloc.

But just in case, we'll use an 'if' to guarantee zero.

[ and the nice thing is, since the value is known at ]
[ compile time, that 'if' test plus subordinate loop ]
[ can be discarded by the compiler as long as it's 0 ]

Reference(s):
. <pids> introduced (PIDS_noop > 0)
commit 7e6a371d8a
. top employs PIDS_noop at 'new' time
commit f1bd82ff07
. <pids> relocated PIDS_noop (PIDS_noop == 0)
commit e7585992d9

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-08-19 20:46:39 +10:00
Jim Warner
8c624ca9dc top: fixing command line parsing errors is now a habit
Ok, I admit it. I'm now tired of cleaning up after me.

This is the 3rd related tweak after that '-1' argument
was originally introduced. And with this patch we will
once again properly honor the '-o' and '-u|U' switches
without a need to be followed by an additional switch.

[ one can follow my unfortunate trail of alterations ]
[ beginning with my most recent fix referenced below ]

Reference(s):
commit e3bad0687d

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-07-04 20:40:53 +10:00
Jim Warner
876aff8584 library: correct the #define FALSE_THREADS, <PIDS> api
Awhile back, that former QUICK_THREADS #define evolved
into the development (only) FALSE_THREADS which can be
used to ensure a 'duplicate ENUM' convention is output
when certain string fields can't be easily duplicated.

Unfortunately, that original implementation was marred
with zeros being displayed for /proc/$$/meminfo fields
in all the child threads for a multi-threaded process.

So this commit corrects that zero memory field buglet.

Reference(s):
. QUICK_THREADS becomes FALSE_THREADS
commit c546d9dd44

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-07-04 20:40:53 +10:00
Jim Warner
105de6264c misc: adapt 3 programs to some enum changes, <meminfo>
That preceding commit corrected a little mismanagement
regarding the MEMINFO_MEM_CACHED enumerator, which was
used in the following programs: free, top plus vmstat.

This patch simply adapts those programs to use the new
MEMINFO_MEM_CACHED_ALL enumerator, which reflects both
the 'Cached' plus 'SReclaimable' values they expected.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-06-04 21:36:23 +10:00
Jim Warner
dbc880edd3 library: correct 'used' memory calculations, <meminfo>
The <meminfo> module attempted to duplicate the former
sysinfo memory calculations wherein 'SReclaimable' was
added to 'Cached' for the 'kb_main_cached' equivalent.

But, this original approach was wrong for two reasons.

1. The addition occurred too late to impact the 'USED'
calculation which could then cause an underflow in the
top memory display if 'SReclaimable' was heavily used.

2. In changing the actual /proc/meminfo 'Cached' value
it meant that users could not rely on that proc(5) man
page when interpreting the MEMINFO_MEM_CACHED results.

So this commit adds a new enumerator for the inclusive
cached amount plus repositions the calculation so that
a MEMINFO_MEM_USED result will exclude 'SReclaimable'.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-06-04 21:36:23 +10:00
Jim Warner
e3bad0687d top: correct functioning of the '-p' command line args
With the introduction of a new '1' command line toggle
I have gone and broken a provision of the '-p' command
line switch (pids monitoring). Multiple pids could not
be specified through the use of comma delimited lists.

Thus, this commit simply corrects that newly added bug
which was born in the 'adjustment' commit shown below.

Reference(s):
. adjustment to '-1' implementation
commit 3e5c950a5e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-06-04 21:36:23 +10:00
Werner Fink
e04394ef24 sysctl: Print lines longer than 1024 chars
as well do not open /proc/sys files if only the names of the
system control names of the kernel parameters should be shown.
Avoid leaking tmpname in case of a pattern mismatch.

Signed-off-by: Werner Fink <werner@suse.de>
2017-05-22 22:34:29 +10:00
Craig Small
aa41c309dd kill: -l space between name parses correctly
This was supposed to be just a cherry-pick of the referenced
commit. However there were two problems:
 1. kill code was moved out to its own file
 2. strtosig() had a latent bug where signal numbers were not
 converted to names.

Original note:
kill -lHUP would work correctly, but kill -l HUP would not.

The list option in kill was hit by a quirk of getopt_long where an
option with an optional argument would not attempt to get the argument
beyond the space, even though a mandatory argument would do that.

The fix is a kludge to scan to the next argument and if it looks
like something we can use, use it. Lucky for us, the list option is
one where parsing can stop immediately.

Thanks to Brian Vandenberg for the way forward.

References:
 http://stackoverflow.com/questions/1052746/getopt-does-not-parse-optional-arguments-to-parameters
 https://bugs.debian.org/854407
 commit 537cea324b121f54744369425332c256aa84a181
2017-05-22 22:15:59 +10:00
Jim Warner
3ad417c0c0 top: address the argument parsing quirk involving '-h'
There exists the possibility that a 'putp' call can be
issued before the 'setupterm' invocation has occurred,
as is reflected in a bugzilla report referenced below.

Strangely, such a SEGV isn't always triggered as logic
would suggest it ought to be. I experienced a fault in
these environments with the associated curses version:
. archlinux, procps-ng 3.3.12, ncurses 6.0.20170429
. fedora-25, procps-ng 3.3.10, ncurses 6.0.20160709
. opensuse-42.2, procps-ng 3.3.9, ncurses 5.9.20140201
. gentoo, procps-ng 3.3.12, ncurses 6.0.20150808
. slackw-14.2, procps-ng 3.3.12, ncurses 6.0.20160910

Whereas under these environments there was no problem:
. ubuntu-17.04, procps-ng 3.3.12, ncurses 6.0.20160625
. debian-test, procps-ng 3.3.12, ncurses 6.0.20161126
. mageia-5.1, procps-ng 3.3.9, ncurses 5.9.20140323

[ as an aside, the expected result in the bug report ]
[ is incorrect and should mention the '1' parameter. ]

[ however, until release 3.3.13 when the '1' becomes ]
[ a valid switch, numbers are not detected when used ]
[ with any switch which doesn't require an argument. ]

[ you're welcome to treat that as a separate bugglet ]

Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1450429

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:16 +10:00
Jim Warner
c0ce5793e8 NEWS: update/alphabetize enhancements for next release
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
fd95a61652 ps: have now added the NUMA node field display support
Reference(s):
https://gitlab.com/procps-ng/procps/issues/58

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
6002603e2c top: now includes that NUMA node field display support
Reference(s):
https://gitlab.com/procps-ng/procps/issues/58

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
3d39e4fd88 library: set stage for NUMA node field display support
In response to that suggestion referenced below, these
changes allow display of task/thread level NUMA nodes.

Currently, only the 'top' program offers any NUMA type
support and it is limited to the Summary Area display.
With this commit both the 'top' and 'ps' programs will
be able to display NUMA nodes associated with threads.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/58

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
618a813baa misc: eliminate all those remaining gcc -Wall warnings
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]

proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]

ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]

watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
a235c9b0be top: correct man page alphabetical order for -E switch
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
6644b1a646 library: eliminate a redundant conditional, <PIDS> api
library: eliminate a single redundant conditional test

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
253ac7f709 library: improve <STAT> cpus offline/online management
When those standardized 'derived' TIC enumerators were
introduced, a problem with potential DELTA distortions
was also introduced when toggling cpus offline/online.

It has always been true that the 1st (summary) line in
/proc/stat will experience a decrease in total tics if
a new cpu is brought online. Such decreases are mostly
due to reductions in 'idle' and 'iowait' tics. Exactly
why such a counterintuitive phenomenon should occur is
a mystery, but this has been acknowledged in proc.txt.

A separate potential distortion arises with individual
cpus. And, here it extends to both bringing processors
online plus taking them offline too. When that happens
the order of the cpus array tracking is upset, placing
the 'new' values in some other processor's array slot.
But even if we were to occupy the same slot, the issue
regarding reductions in 'idle' & 'iowait' still apply.

In all cases, when a DELTA field was found to be minus
it was forced to zero via the 'TICsetH' macro. However
the 'derived' calculations are subject to new forms of
distortion with their own DELTA values. For example we
could find DELTA_SUM_USER + DELTA_SUM_SYSTEM exceeding
DELTA_SUM_TOTAL, an illogical/inappropriate condition.

So this commit moves former protections for individual
cpus to the stat_derive_unique() function and modifies
it to also extend protections to the 'derived' values.
In the process we now protect the cpu 'summary' counts
which were unfortunately previously overlooked (oops).

Reference(s):
. 'derived' types introduced
commit 2c86c4984a
2017-03-29 22:10:56 +11:00
Jim Warner
3e5c950a5e top: make command line switch parsing even more robust
This program has always tried to maintain an extermely
robust command line parsing procedure, far more robust
that what's available with the getopt stuff. But, with
the introduction of our first numeric switch it should
have been made even more robust than, in fact, it was.

This commit will now accomplish such a desirable goal.

Reference(s):
. added '1' command line switch
commit 5e708c5db7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-29 22:10:33 +11:00
Jim Warner
810e1d38ab top: just update all of the copyright dates in sources
[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Jim Warner
835ee677d0 top: by default, show cmd line vs. cmd name at startup
All of top's display was designed to fit into an 80x24
terminal. This includes the help screens plus both the
Summary and Task Areas, assuming no saved config file.

With release 3.3.10, the startup defaults were changed
assuming ./configure --disable-modern-top wasn't used.
This was done in the hope of introducing some users to
unknown capabilities such as colors, forest view, etc.

The purpose of this commit is to coax a few more users
into possibly exploring another capability: scrolling.
We do so by tweaking the default startup display so as
to show full command lines. Now, when things no longer
fit in 80x24, horizontal scrolling might be exploited.

[ of course, this can be reversed with the -c switch ]

[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Jim Warner
5e708c5db7 top: provide -1 command line switch as 'Cpu(s)' toggle
If built without ./configure --disable-modern-top, the
program displays each cpu individually providing there
is sufficient vertical screen real estate. For massive
SMP environments this will necessitate use of a config
file where the cpu summary toggle ('1') could be saved
via the 'W' command. But, an rcfile may not be viable.

So this commit introduces a '1' command line switch to
emulate exactly the effects of the interactive toggle.

And since it is our first numeric switch some existing
parsing logic had to be changed slightly. Such changes
are, in truth, an improvement. For example, instead of
seeing "inappropriate '2'" with ./top -2 we'll now see
the vastly more appropriate error "unknown option '2'.

References(s):
https://gitlab.com/procps-ng/procps/issues/55

[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Jim Warner
b2bd65407a top: provide -E command line switch for memory scaling
In their 3.2.7 version of top, Redhat introduced an -M
switch to automatically scale Summary Area memory data
to avoid truncation (and the resulting '+' indicator).

The procps-ng top does not employ suffixes with memory
data nor does it allow for different scaling with each
separate value. Rather, scaling appears at line start.

If built without ./configure --disable-modern-top, the
Summary Area memory will be scaled at GiB which should
lessen chance of truncation. Otherwise KiB was used to
reflect such memory, increasing the truncation chance.

And while 'W' can be used to preserve some appropriate
scaling value, there are arguments against such rcfile
approaches as cited in the issue and bug report below.

So this commit will bump the Summary Area memory scale
factor from KiB to MiB when using --disable-modern-top
as a concession to that Redhat bug report noted below.

And it also introduces a new command line switch which
can force any desired scaling regardless of the rcfile
or which ./configure option might have been specified.

[ for top's help text we'll show 'E' as if it were a ]
[ switch without arguments in order to keep the help ]
[ text displayable without wrap in an 80x24 terminal ]

[ the man page, however, will show all k-e arguments ]

Reference(s):
https://gitlab.com/procps-ng/procps/issues/53
https://bugzilla.redhat.com/show_bug.cgi?id=1034466

[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Jim Warner
f318be467b top: show fewer decimal places for memory (by default)
After much reflection I've come to the conclusion that
displaying 3 decimal places (usually) when memory data
had been scaled is no longer optimal with today's ever
increasing amounts. And given that not all task memory
fields are the same widths, inconsistencies can easily
arise as illustrated and discussed in the issue below.

Instead of unilaterally reducing the number of decimal
places, this commit will sneak in such a change via an
existing configure option that was very likely unused.

The former 'disable-wide-memory' option has now become
'enable-wide-memory', which can be used if the current
behavior (3 decimal places) is preferred. Without that
option, whenever memory is scaled beyond KiB, just one
decimal place will be shown in Summary and Task areas.

And Task area field width will no longer be changed by
this revised configure option. Instead, all such field
widths will now be fixed at the former maximum values.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/50

[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Jim Warner
7468e229e8 top: correct alphabetic ordering with some enumerators
[ this patch has been adapted from the master branch ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-03-16 22:08:07 +11:00
Craig Small
ff05573f0d pkill: Return 0 if successfully killed process
Original report:
When trying kill a process with insufficient privileges (see blow),
pkill displays the error message “... failed: Operation not permitted”,
but returns 0. Surely it should return 3?

$ pkill syslogd ; echo $?
pkill: killing pid 373 failed: Operation not permitted
0

Return value 0 means one of more things matched. For a pgrep (which
shares code with pkill) this makes sense, there was a match. It seems
wrong for pkill to return 0 when it in fact could not do what you told
it to.  However return value 3 means a fatal error and it's not fatal.

Looking at other programs when trying to kill things it cannot kill.
shell kill returns 1, procps kill returns 1, killall returns 1, skill
returns 0 (and says it was successful!, ah well poor old skill)

The consensus seems to be that you return 1 if you cannot kill it, even
if you found it. In other words the return value for both not found and
not able to kill it is the same.

pkill only returns 0 if something was killed. This means we found a
match AND the kill() system call worked too.

References:
 https://bugs.debian.org/852758

Signed-off-by: Craig Small <csmall@enc.com.au>
2017-02-04 12:00:24 +11:00
Craig Small
1f094f51f1 NEWS: Very minor typo fixed
Signed-off-by: Craig Small <csmall@enc.com.au>
2017-02-04 11:07:21 +11:00
Jim Warner
a2d2b89ce0 NEWS: updated with the two most recent program changes
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-02-04 11:07:06 +11:00
Jim Warner
a81a74a1df top: adapt the master branch XDG specification support
This patch adapts a master branch commit to our newlib
branch. Shown below was that original commit msg text.

------------------------------------------------------
top: Add unobtrusive XDG support

By default the file HOME/.toprc will be prefered.  This ensures there
should be minimal breakage even if this file is later created by some
other means.  Otherwise we will follow the new behaviour described by
the XDG Base Directory Specification:

If the XDG_CONFIG_HOME environment variable is available we will attempt
to use this as XDG_CONFIG_HOME/procps/toprc otherwise we will fall-back
to HOME/.config/procps/toprc instead.

Signed-off-by: Earnestly <zibeon@gmail.com>
------------------------------------------------------

Reference(s):
. master branch original
commit 0a0f7d60e309c13c8a399bc2187bed6e3e156b43
. discussion thread
https://gitlab.com/procps-ng/procps/merge_requests/38

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-02-04 11:07:06 +11:00
Jan Rybar
9252a04eae pgrep: warning about 15+ chars name only if zero matches found
This avoids situations where longer regex which matches short-named proc
is used. Test for pgrep updated.

This is the newlib update of 5d12be1b7e8cc690a4d8778754aae5db4c07db2b
Signed-off-by: Craig Small <csmall@enc.com.au>
2017-01-26 16:52:23 +11:00
Craig Small
2598e9f2ce documentation: Update pids manual pages
Updated the full suite of manual pages for the procps_pids_*
functions. The only one missing is procps_pids_get which
may not be required.
2017-01-05 09:44:04 +11:00
Jim Warner
ea930f6f9e library <stat>: input file buffer size must be dynamic
Since its introduction, our evolved /proc/stat API has
relied on a static buffer of 8192 bytes. This approach
is probably Ok for other /proc files but it would only
accommodate around 100 processors. If such a threshold
were exceeded then this interface could never succeed.

Now days 100 processors doesn't seem at all excessive.

So this commit trades that static buffer for a dynamic
self-tuning one. And since so much former top CPU code
was already rolled into this module, we just stole the
already proven top dynamic buffer management code too.

[ this also meant switching low level unbuffered I/O ]
[ calls to standard library buffered I/O calls. that ]
[ is exactly what <slabinfo> and <diskstats> employ. ]

Reference(s):
. 1st gen readstat introduction
commit a410e236ab

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
282ee362f0 library <stat>: improve response to cpu offline/online
With the addition of those new derived SUM values, any
CPUs taken offline or brought online would distort the
historical (delta) results.  So this patch just forces
a history reset when such transitions are encountered.

Reference(s):
. derived SUM provisions introduced
commit 2c86c4984a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
f82ac70e13 library <slabinfo>: make read function name consistent
For each of those interfaces employing a priming read,
all the other 'read' functions begin with the module's
name except this guy which began with 'read_slabinfo'.

Now, they'll all begin with their module name then end
the same with a '_read_failed' boolean hinting suffix.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
e524e48138 library: eliminate distorted history 1st time switches
Upon reflection, at the point where the 'priming read'
was introduced, any possibility of history distortions
was also eliminated.  This was true because all of the
'old' (zeroed) data will have been replaced with 'new'
data whenever a user finally calls get, select & reap.

Thus, any DELTA values will automatically reflect that
interval between 'new' and subsequent retrieval calls.

[ diskstats didn't actually employ a 1st time switch ]
[ like the others so we have changed a comment only. ]
[ but that module will retain something similar used ]
[ inside node_update whenever a new node is created. ]

Reference(s):
. priming read added to slabinfo
commit 5d5a52a380
. priming read added to diskstats
commit ecd64f4445
. priming read added to meminfo, stat, vmstat
commit 1a2b62c779

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
904f4c3b35 top: exploits several <stat> new category calculations
This commit just exploits those new library provisions
for tic categories, introduced in the preceding patch,
which had been prompted by the issue referenced below.

[ ok it also corrects the top graph for system usage ]
[ since this turkey failed to include tics for these ]
[ two interrupts: STAT_TIC_IRQ and STAT_TIC_SOFTIRQ. ]

Reference(s):
https://gitlab.com/procps-ng/procps/issues/48

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jim Warner
2c86c4984a library <stat>: standardized new category calculations
This commit arose out of the discussion (and research)
surrounding the issue cited below. It is an attempt to
consolidate and standardize the calculation of jiffies
categories (e.g. 'idle', 'busy', etc.) once & for all.

Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in
case anyone, in the future, decides to calculate usage
based upon elapsed time * Hz (like top does in process
level %CPU stats). In such an event, a total number of
CPUs or NUMA Nodes would be needed for proper scaling.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/48

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jim Warner
12e070dd5f library: ensure 'namespace' types treated consistently
Unlike the ps kludge under the master branch to ensure
that namespaces appear the same under both 32 & 64-bit
models, this newlib branch already used a proper type.

However source data still carried the original type as
'signed long' versus that more proper 'unsigned long'.

So, this patch makes sources & destinations identical.

Reference(s):
. master branch ps kludge
commit c41c614b0c

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jim Warner
66e8e2723d ps: finish purging those references to PIDS_WCHAN_ADDR
Aw shucks, not all support for this defunct enumerator
was removed via the commits shown below (but, is now).

[ what remained were just variables named after that ]
[ deprecated/deleted enumerator, but still & all ... ]

[ plus, i have left the doc/libproc.3 file untouched ]
[ since it already appears badly out of date anyway! ]

Reference(s):
. ps references partially purged
commit 66c4024d75
. enumerator purged from library
commit 912075605b

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jan Rybar
5602dd04e1 library: don't strip off prefixes from the wchan names
This commit will resolve the RedHat Bugzilla #1322111.

[ import from identical commit against master branch ]
[ but without trailing whitespace, thank you so much ]

Imported by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:07:00 +11:00
Jim Warner
1c0d54e963 ps: now made responsive to 32 or 64-bit address widths
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>
2016-12-07 22:07:00 +11:00
Jim Warner
8ba07209f0 library: accumulated miscellaneous code/comment tweaks
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:07:00 +11:00
Jim Warner
57dfe6f92c top: accumulated misc tweaks to code/comments/man page
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:07:00 +11:00
Jim Warner
e70531a945 library: protect against possible 'refcount' underflow
In each module employing a priming read at 'new' time,
should that read fail, a call to 'unref' will be made.

However, there is a hidden dependency that these calls
must never occur before the context 'refcount' was set
due to the way an 'unref' conditional was constructed.

So this commit just ensures that 'unref' will function
as expected, even if called with a 'refcount' of zero.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:06:59 +11:00
Martin Polednik
b3e8581a30 ps: recognize SCHED_DEADLINE 2016-11-21 21:56:37 +11:00
Jim Warner
f0064ac18f top: tweak some stuff relating to non-displayed fields
In the commit referenced below, in addition to several
tweaks to comments, 3 fields were no longer assured of
being present in the results stacks. However, 2 of the
3 fields might, in fact, be required even if they were
not currently being displayed in any of the 4 windows.

The PIDS_CMD is used in two separate 'Inspect' headers
('Y' command) and the PIDS_ID_EUID is required if that
'User Filter' ('u' or 'U' command) was being employed.

That latter field's inclusion will be made conditional
but the former field must be unconditionally included.

( for old top, PIDS_CMD would have always been there )

Reference(s):
commit 4e4debda9b

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-16 08:24:32 +11:00
Jim Warner
66c4024d75 ps: respond to loss of that PIDS_WCHAN_ADDR enumerator
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>
2016-10-16 08:23:38 +11:00
Jim Warner
912075605b library <stat>: remove that PIDS_WCHAN_ADDR enumerator
Removing the Item_table 'stat' oldflags for WCHAN_ADDR
was wrong since that 'stat' field is not a constant 0.
Rather, it could assume these 3 values: -1, 0, and +1.

I have not been able to pin down a '-1' result, but it
probably means some sort of permission error (-EPERM).

The '1' or '0' values were supposed to distinguish the
tasks that were or were not blocked (whether there was
a wchan address). However, in practice there is little
correlation between those values and availability of a
kernel symbol in /proc/$$/wchan (perhaps due to race).

Anyway, the real point is that a 'stat' wchan does not
now intentionally contain an address. Thus, outputting
'ffffff', '-' or '1' in programs like ps is senseless.

So this patch just eliminates PIDS_WCHAN_ADDR from our
item enumerators leaving only the PIDS_WCHAN_NAME guy.
Now the new library can't be blamed for bad addresses!

Reference(s):
. removed Item_table 'oldflags'
commit c4aa6c0ab4
. linux removal of wchan addresses
commit b2f73922d119686323f14fbbe46587f863852328

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-16 08:23:38 +11:00
Jim Warner
f3ec7f0032 top: make that 'forest view' just a tad more efficient
It makes no sense to begin our tracked nested level at
'1' then later require a '1' to be subtracted from the
level as artwork and indentation is added for display.

By beginning such tracked levels at zero, we can avoid
the need to adjust it & use it directly in a snprintf.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-16 08:23:38 +11:00