The disk partition format translation hint, the actual text and the
printf statements were all diagreeing with each other. This meant
the disk partition output from vmstat was a mess.
Now all the titles and values line up and everything is right-aligned
which looks better than some half-hearted attempt at center-aligned
for titles and right-aligned for values.
Thanks to @goeran for the heads-up in #69
When supplying the -p command to uptime, it does not display any
sections where the value is less than 1; however, after a reboot, this
causes the command to just output "up". Showing 0 minutes when the
system has been up for less than a minute makes it clear a reboot just
occurred.
References:
commit 325d68b7c3
Signed-off-by: Craig Small <csmall@enc.com.au>
When supplying the -p command to uptime, it does not display any
sections where the value is less than 1; however, after a reboot, this
causes the command to just output "up". Showing 0 minutes when the
system has been up for less than a minute makes it clear a reboot just
occurred.
The combined results of merge request #49 without that
overhead plus distortion in this repository's history.
Prototyped-by: Wayne Porter <wporter82@gmail.com>
read huge informations at once as otherwise all files below
/proc/sys, not using the seq_file API at the kernel side,
will return EOF on a second read.
Signed-off-by: Werner Fink <werner@suse.de>
read huge informations at once as otherwise all files below
/proc/sys, not using the seq_file API at the kernel side,
will return EOF on a second read.
Signed-off-by: Werner Fink <werner@suse.de>
Until this patch, top falsely assumed that there would
always be some (small) amount of physical memory after
subtracting 'used' and 'available' from the total. But
as the issue referenced below attests, a sum of 'used'
and 'available' might exceed that total memory amount.
I'm not sure if this is a problem with our calculation
of the 'used' amount, a flaw in the kernel 'available'
algorithms or some other reason I cannot even imagine.
Anyway, this patch protects against such a contingency
through the following single line addition of new code
. if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
The check for less than zero is not actually necessary
as long as the source numbers remain unsigned. However
should they ever become signed, we'll have protection.
[ Most of the changes in this commit simply separate ]
[ a variable's definition from its associated logic. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/64
Signed-off-by: Jim Warner <james.warner@comcast.net>
And we repositioned the kill line (Debian #854407) for
alphabetic integrity and conformance with newlib NEWS.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Until this patch, top falsely assumed that there would
always be some (small) amount of physical memory after
subtracting 'used' and 'available' from the total. But
as the issue referenced below attests, a sum of 'used'
and 'available' might exceed that total memory amount.
I'm not sure if this is a problem with our calculation
of the 'used' amount, a flaw in the kernel 'available'
algorithms or some other reason I cannot even imagine.
Anyway, this patch protects against such a contingency
through the following single line addition of new code
. if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
The check for less than zero is not actually necessary
as long as the source numbers remain unsigned. However
should they ever become signed, we'll have protection.
[ Most of the changes in this commit simply separate ]
[ a variable's definition from its associated logic. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/64
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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>
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>
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>
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 4b44aebd80
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the effective user id would always be present in
each proc_t, thus supporting 'u' filtering, other user
ids would only be present if /proc/$$/status was read.
This commit just puts the 'master' branch top on a par
with the 'newlib' branch when user filtering with 'U'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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>
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 909b37d755
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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-parametershttps://bugs.debian.org/854407
commit 537cea324b121f54744369425332c256aa84a181
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>
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>
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>
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>
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.
[ this patch has been adapted from the newlib branch ]
[ and implemented so as to preserve the existing ABI ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/58
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:627:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]
ps/output.c: In function 'pr_context':
ps/output.c:1273:14: warning: unused variable 'tried_load' [-Wunused-variable]
ps/output.c:1272:16: warning: unused variable 'ps_is_selinux_enabled' [-Wunused-variable]
ps/output.c:1272:16: warning: 'ps_is_selinux_enabled' defined but not used [-Wunused-variable]
ps/output.c:1273:14: warning: 'tried_load' defined but not used [-Wunused-variable]
ps/output.c:1837:18: warning: 'shortsort_array_count' defined but not used [-Wunused-const-variable=]
ps/output.c:1803:18: warning: 'aix_array_count' defined but not used [-Wunused-const-variable=]
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'
ps/sortformat.c: In function 'format_parse':
ps/sortformat.c:241:1: warning: label 'out' defined but not used [-Wunused-label]
ps/stacktrace.c:176:13: warning: 'stack_trace_sigsegv' defined but not used [-Wunused-function]
watch.c: In function 'process_ansi':
watch.c:234:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:237: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>
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
