Under some circumstances the ksh shell doesn't fork new processes
when executing scripts and the script is interpreted by the
parent process. That makes the execution faster, but it means
ksh needs to reuse the /proc/PID/cmdline for the new script name
and arguments while the file length needs to stay untouched.
The fork is skipped only when the new cmdline is shorter than
the parent's cmdline and the rest of the file is filled
with '\0'. This is perfectly ok until we try to read the cmdline
of such process. As the read_unvectored() function replaces
all zeros with chosen separator, these trailing zeros are replaced
with spaces in case of the ps tool. Consequently it appends
multiple spaces at the end of the arguments string even when these
zeros do not represent any separators and therefore shouldn't
be replaced.
With this commit the read_unvectored() function skips the
replacement of trailing zeros and separates valid content only.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1057600
8 digits per memory column is apparently still too low
for systems with 128TB of RAM. Anyway, setting the limit
to 999TB (12 digits) must be sufficient for now as it
produces wide gaps on "regular" computers.
This commit also increases the number of digits per cpu
columns from 2 to 3 as some of them can hit the 100%
maximum in corner cases.
Apparently there are occasions when NUMA nodes may not
always be contiguous. Under such conditions nodes that
were not used would still occupy precious Summary Area
space showing 100% idle, under the '2' command toggle.
With this commit top will no longer display numa nodes
that have no associated cpu when the '2' toggle is on.
But just in case we wish to return to former behavior,
a new #define called OFF_NUMASKIP has been introduced.
And as an aside, a recent refactor mentioned below set
the stage for this patch to be 'self-tuning'. In other
words, if an inactive/non-displayed node should become
active (if even possible), then top will begin showing
such a node automatically with the next screen update.
Unfortunately, all inactive nodes now 'suppressed' are
still accessible via the '3' command. Those nodes will
just be displayed as empty (no associated cpus shown).
This is not really a top problem but more of a libnuma
and/or user deficiency. The library lacks the means to
validate a node id and the user then input a node that
was not even shown under a '2' toggle Summary display.
( too bad libnuma does not offer an 'is_node_active' )
( type function so top could warn a user when such a )
( discontinuous node was requested using his '3' cmd )
( sure, top could achieve this objective himself but )
( that would require making yet another array global )
( which i'm just not in the mood to do - besides, we )
( have already made enough concessions to libnuma.so )
Lastly, an existing #define (PRETEND_NUMA) was changed
to 'disable' node #1 so as to simulate a discontinuous
node. This allows testing of the '2' and '3' commands.
Reference(s):
http://www.spinics.net/lists/util-linux-ng/msg08671.html
. set stage for self tuning
commit f12c0d5c6e
Signed-off-by: Jim Warner <james.warner@comcast.net>
SIGCONT is a continue signal. It seems that some zsh setups can send
this signal, causing ps to abort. This is not what "continue" means.
This change just uses the default handler which will continue a stopped
process.
References:
http://bugs.debian.org/732410http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=32251
Signed-off-by: Craig Small <csmall@enc.com.au>
To assist translators, the help lines are split so that each translation
chunk has one option. This gives bonus of if we add or change an option,
only that option remains untranslated rather than the entire help block.
Reference:
http://www.freelists.org/post/procps/procpsng-for-Translation-Project,1
Signed-off-by: Craig Small <csmall@enc.com.au>
A recent change involving a one cycle stderr redirect,
to handle a libnuma potential transgression, failed to
follow normal global variable naming conventions. This
patch will capitalize the 1st letter of 'Stderr_save'.
Reference(s):
commit 35dc6dcc49
Signed-off-by: Jim Warner <james.warner@comcast.net>
Excluding those special X_XON/X_XOF enums, which might
not even be present, restore strict collating order of
all the case labels in the task_show switch statement.
Also, adjust a few sort callbacks for the same reason.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Surprisingly the code for the 'st' column was added in the past,
but wasn't enabled. The vmstat manual already contains the 'st'
column and this commit finally enables the feature.
This is a rework of the merge request #5 that unconditionally
forced the output to cross the 80 chars border.
With this commit users can switch to the wide output mode
with the -w option.
The recent addition of namespaces, combined with those
potential suse out-of-memory fields, means that we are
close to the maximum number of fields poor ol' top can
display. Imagine, the really old top was limited to 26
fields (28 with the suse hack) and this top had neared
the version 'g' rcfile limits which were a healthy 55.
This patch adds another 15 fields to the maximum while
making it even easier to increase in the future. Also,
top still silently accommodates older config files all
the way back to the original pre-ng version top-3.2.8!
Signed-off-by: Jim Warner <james.warner@comcast.net>
While 'invisible' thread subdirectories are accessible
under /proc/ with stat/opendir calls, they have always
been treated as non-existent, as is true with readdir.
This patch trades the /proc/#/ns access convention for
the more proper /proc/#/task/#/ns approach when thread
access is desired. In addition some namespace code has
been simplified and made slightly more efficient given
the calloc nature of proc_t acquisition and its reuse.
Reference(s):
commit a01ee3c0b3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is inspired by the 'minimize numa overhead'
patch. It trades the use of subscripts for pointers to
avoid gcc repeated subscript offset calculation bloat.
Now, throughout the cpus_refresh function, a subscript
will be resolved just once & this will (dramatically?)
reduce the path-length taken for each and every frame!
For example, a non-optimized compilation could produce
400+ fewer machine instructions through pointer usage.
[ ok, optimized compiles only save 18+ instructions! ]
Lastly, any residual 'symmetry only' crap is now gone!
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent libnuma potential corruption problem solution
has caused me to reevaluate some associated numa logic
for efficiency. Here is a summary of the problems that
exist with current libnuma/user possible interactions:
. Whenever the numa library was present extra overhead
would always be incurred in maintaining the node stats
even when the '2' or '3' commands were not being used.
. As part of such overhead a separate loop was used to
reinitialize each cpu/node structure with each display
cycle so that prior accumulated totals were preserved.
Again, it didn't matter if numa data was really shown.
This commit attempts to refocus on the 'critical path'
costs in a running top by optimizing for the occasions
when numa node data is not being displayed. Under such
conditions, no extra overhead will be incurred whether
or not a distribution has the libnuma library present.
To achieve this goal, some additional overhead will be
incurred, but only when actually displaying numa data.
And all such new costs have been minimized in spite of
the gcc inclination to duplicate subscript resolution.
Reference(s):
commit 24bd950cb2e1722d459461f0f9c0c30a4b9ffdaa
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent libnuma potential corruption problem solution
suggests that libnuma could change in the future so as
to not spew to stderr. This then raises a question how
top could exploit any such library change since we are
currently locked into version #1 of the library by way
of our dlopen("libnuma.so.1", RTLD_LAZY) runtime call.
While not an ultimate solution, this commit will first
try for the most recent version of that library during
top's startup before trying the original libnuma.so.1.
We do this via the unqualified library soname symlink.
For this new dlopen() call to succeed, technically the
numa 'devel' package would usually have been required,
but that's not always true with every distro. And when
the libnuma.so symlink isn't present, it can always be
manually added should a newer & better behaved library
arrive & users tire of the stderr warning at top exit.
Reference(s):
commit 24bd950cb2e1722d459461f0f9c0c30a4b9ffdaa
Signed-off-by: Jim Warner <james.warner@comcast.net>
Confession is supposed to be good for the sole, right?
After a senior moment regarding the 'x' toggle quirks,
and thinking top had somehow regressed, I concluded an
additional explanatory note might well be appropriate.
Those quirks were already documented under the 5d & 5e
topics. But there was no such caution documented under
the 'x' command explanation itself, found in topic 4c.
Signed-off-by: Jim Warner <james.warner@comcast.net>
There is a chance that the libnuma library may corrupt
top's display with some stderr warning messages in the
event something under /sys/devices/system/node/ cannot
be accessed. And, while 2 overridable 'weak' functions
are provided to alter such behavior, we can't use them
since top dynamically links to the library via dlopen.
This commit will redirect stderr to '/dev/null' during
just the first screen display cycle. Thus we can avoid
the corruption which would have remained visible until
the underlining screen row's data had finally changed.
Lastly, this patch should allow such a library warning
to actually appear when one finally exits our program.
[ i think the libnuma folks should consider changing ]
[ the error/warning interfaces to accommodate dlopen ]
[ rather than forcing something like the ugly kludge ]
[ we have employed or libnuma dependency on everyone ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=998678
Signed-off-by: Jim Warner <james.warner@comcast.net>
Library systemd-login offers possibility to display
name of a systemd slice unit for specific pid.
This patch adds output option "slice" which will
show name of systemd slice unit.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
This commit introduces support for special %PPID value that
can be passed to the -o option as a substitution for parent
PID. It also allows users to use two additional separators
for omitted PIDs - colon and semicolon.
To assist the translators, each option is a separate string.
This means if we add/change/delete an option the remaining ones
will just keep working and only the impacted option needs some
translation work on it.
As the sysvinit becomes obsolete, some of the bundled tools
need to find a new home. The procps-ng project seems to be
the most suitable project for adopting the pidof tool.
This commit introduces a redesigned version of pidof
that satisfies the LSB requirements.
In corner cases the behaviour might differ from the former
one as the new version doesn't use any stat(2) calls.
Some Debian pbuilders error out on some of the tests because
they cannot find kill to kill the test processes. Now if we
cannot find kill we skip those lot of tests.
Still need to work out why the S390 doesn't like test_sched
References: http://bugs.debian.org/725743
When Other filtering was introduced the nature of what
constituted a displayed row changed. No longer would a
task_show() call guarantee that another line is shown.
Rather, a non-empty string must have also been tested.
Unfortunately, when any task window was being filtered
for 'idle' mode or a particular 'user', the proc index
was incremented twice due to the perils of copy/paste.
Combining such an index increment with the new test of
task_show results works fine if filtering is inactive.
This was a particularly insidious bug which meant that
an adjacent task would be skipped whenever the current
task met 'idle' and/or 'user' filter criteria, and was
not otherwise excluded due to 'Other' filter criteria.
And, since it was the very next task that was ignored,
the bug was very susceptible to a window's sort order.
This could be illustrated when filtering on some user,
while sorting on PID. Then, toggling Forest View could
make otherwise unseen tasks appear and then disappear.
User workarounds are possible via interactive commands
trading the 'i' and 'u'/'U' provisions for the 'o'/'O'
other filtering capability thus avoiding an extra i++.
But that is certainly less than ideal and doesn't help
the 3.3.7 and 3.3.8 distorted command line provisions.
( this little buggie may end up costing me my pocket )
( protector, my coding badge & maybe even my cubicle )
Reference(s):
http://www.freelists.org/post/procps/Idle-elides-nonidle-processes
. bug originated with 'Other' filtering
commit 5edc6fb317
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adds the final newline when exiting 'Batch'
mode. Interestingly, it has been missing since release
3.3.5 but undetected until the Redhat bugzilla report.
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1008674
Signed-off-by: Jim Warner <james.warner@comcast.net>
Additional errors resulting from merge request #13 are
being addressed in this commit. They involve two cases
of trailing whitespace and one xwarnx printf type arg.
Reference(s):
http://gitorious.org/procps/procps/merge_requests/13
. earlier build-sys fix
commit e2242cb943
. original merge
commit dd6f24dbed
Signed-off-by: Jim Warner <james.warner@comcast.net>
While a 'make dist' appeared to work fine without this
patch, the nsutils.h file was missing from the include
subdirectory. Thus the tarball could not support make.
Reference(s):
http://gitorious.org/procps/procps/merge_requests/13
commit dd6f24dbed
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previously the shared memory column was always zero
for 2.6 series kernels (and later) due to the fact,
that the value was taken from the MemShared entry
that disappeared with 2.6 series kernels.
Later a new Shmem entry appeared in the /proc/meminfo
file and the 'shared' column now displays either
the MemShared or the Shmem value (depending on their
presence - the presence is mutually exclusive).
If none of the two entries is exported by the kernel,
then the column is zero.
