When autogroups are active programs such as renice and
nice are basically useless because the nice value will
only affect the target task priority relative to other
processes in the same autogroup. So to accomplish what
we thought of as renice, /proc/<pid>/autogroup must be
changed. Altering a single member in an autogroup will
also affect every other member of that same autogroup.
Since top's renice provision ('r') suffers constraints
like those of the stand alone nice/renice programs, we
will now provide a means to manipulate that nice value
found within some process' /proc/<pid>/autogroup file.
[ to alter this file for other user's tasks requires ]
[ root privileges, as does setting a negative value. ]
[ however, unlike that 'r' command, this new command ]
[ allows raising *and* lowering all positive values. ]
Reference(s):
. Aug 2021, autogroups added to librady
commit 631e5d91f3
. Aug 2021, autogroups added to top
commit b789b46f84
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ you wouldn't believe how many back-and-forths were ]
[ involved in Craig convincing me there were several ]
[ inconsistencies. i am so dense sometimes (often?). ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This just updates the copyright dates in the documents
where I was already represented. Others are unchanged.
Signed-off-by: Jim Warner <james.warner@comcast.net>
As the issue cited below illustrates, a pids namespace
with proc mounted as subset=pid denies our library any
access to non-task data. In top's case, the result was
a fatal error message which involved "cpu statistics".
With this patch top will now assume an error involving
global cpu (stat) or memory (meminfo) data means we're
running under a restricted pids namespace. As such, an
attempt will be made to still display task level data.
[ if our assumption is incorrect, it's of no matter. ]
[ instead of a fatal error, we'll still try to offer ]
[ a user some minimally useful bit of functionality. ]
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/227https://www.freelists.org/post/procps/three-for-newlib,1
. 1st cut at subset=pid
commit bcb837b8c7
Signed-off-by: Jim Warner <james.warner@comcast.net>
After the stage had been set in the previous patch, in
this patch we will actually implement those background
updates via 3 separate threads. The design was simple:
. the do-while loops have now been made truly infinite
. 2 semaphores per thread allow needed synchronization
. 1 semaphore will provide for each thread to sem_wait
. 1 semaphore will provide for display o/p to sem_wait
. and all 3 thread's program name was made descriptive
A complication was the potential for a signal directed
to one of our new threads. Rather than having a thread
try to deal with such signals, we pass a mask with all
signals blocked at pthread_create time. Thereafter any
subsequent signals are forwarded to the parent thread.
[ also sigprocmask was exchanged for pthread_sigmask ]
[ since warned about use "in multithreaded process". ]
[ plus we also modified each of those POSIX comments ]
[ about 2004 to agree with current signal-safety(7). ]
Sadly, after all this effort there were no performance
benefits to having separate threads. In fact there was
a measurable performance degradation when running with
ever smaller delay intervals. But even with a delay of
1/10 second the 'real' cost increase is only about 1%.
There is one way whereby any additional costs might be
eliminated (at least seemingly). One could introduce 2
separate sets of contexts for each of those 3 threads.
Then retrieval & display could be overlapped. However,
the resulting display wouldn't represent the real-time
results. Rather it would be stale by 1 delay interval.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For quite some time now, top has stood out like a sore
thumb regarding the approach to cmdline options & help
text. Only short options were used and that same help
text was displayed for '-h' (help) plus 'v' (version).
[ also, top 'rolled his own' when it came to parsing ]
[ options while avoiding that getopt implementation. ]
Well, with this commit all of that has changed and top
now has added a long form of his options. Additionally
he employs getopt_long() for the bulk of that parsing.
[ however, top will still avoid separate fputs calls ]
[ characteristic of other procps-ng programs when it ]
[ comes to help. rather all such text is one string. ]
Along the way, the following major getopt deficiencies
were addressed, assuming the absence of a new #define:
* an equals sign ('=') is allowed on both option forms
* whitespace is allowed before & after the equals sign
* optional arguments needn't abut their related option
for short form nor is an '=' required with either form
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit shown below introduced two abreast printing
for %Cpu statistics. But, the Memory & Swap lines have
always been printed on separate lines when '4' was on.
With this commit, those lines will now be treated just
like %Cpu stats, either separate lines or two abreast.
Reference(s):
. May 2020, added '4' toggle for 2 abreast
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm about to break older top rcfile compatibility when
preserving those two new toggles. And, though this has
happened several times over the years, we never issued
any warnings that such thing was just about to happen.
So, this patch corrects the long standing shortcoming.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When implementing that earlier '4' toggle, in response
to the issue referenced below, I got to thinking about
those environments with massively parallel processors.
Such environments may not benefit from the '4' toggle.
So, I decided to implement a feature that could enable
use of those '1' and/or '4' toggles no matter how many
active processors top may have ultimately encountered.
With the new '!' toggle, adjacent cpus can be combined
to any degree, represented as a single cpu group/line.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the back of my mind, I've always wanted to enable a
two abreast cpu display. Folks with massively parallel
machines must surely have been frustrated with the '1'
toggle when Off (individual cpus in the Summary Area).
So, I'll use that recently raised issue shown below as
a justification for finally implementing this feature.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
Currently, it isn't possible to establish an 'Inspect'
pipe that relies on SIGINT to end. That's because this
signal will also end the parent process (top) as well.
So this patch will temporarily ignore that signal when
processing any 'Inspect' pipe, allowing one like this:
. pipe ^I Trace Calls ^I /usr/bin/strace -r -p %d 2>&1
Signed-off-by: Jim Warner <james.warner@comcast.net>
The issue cited below really dealt with preserving the
'Other filter' criteria in the rcfile. But as an aside
the htop 'F6' feature (collapsed children) was raised.
I took that as an implied challenge and decided to try
implementing a similar feature in top. So, this commit
will now provide a brand new forest view toggle ('^V')
which will be used to collapse/expand forked children.
[ this patch will also lead to additional patches in ]
[ support of more rational vertical scrolling, since ]
[ many more tasks might now be hidden in some window ]
Reference(s):
. where this secondary issue was raised
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
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/53https://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>
This commit just eliminates an error message no longer
needed under that newlib <pids> interface. Plus, a few
enumerators in the header weren't in alphabetic order.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The newlib informal cutoff for kernel support seems to
be around release 2.6. This commit eliminates any such
support for really old 2.4 and 2.5 kernels within top.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adapts top to exploit the new <proc/pids.h>
interface. And it appears to have reduced top's weight
by a considerable margin. Gone were the sort callbacks
and manipulation of those library flags. Gosh, all top
needs to do now is track some enumerators of interest.
[ whoa, wait just a damn minute. it now appears some ]
[ that weight loss was solely the result of a theft. ]
[ jeeze, we turn our back for just a minute & newlib ]
[ up & steals our pids hashing logic for his history ]
[ needs. oh well, i guess life's just not that fair. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the dust is settling following an initial API
library effort, it is apparent my naming standards may
not have always been observed. This was a minor crime,
since those standards are unwritten (& not apparent?).
Basically, top has always capitalized the first letter
of global variables in an effort to distinguish global
definitions from local variables later in the program.
So this patch alters the new API variables to conform,
while also explicitly using 'context' for key structs.
Lastly, top now employs the new '#include <proc/name>'
conventions for the new/converted module header files.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is mostly about eliminating code, now that
a library is responsible for the cpu tics maintenance.
The top program will continue to provide numa support,
without involving the library in any of those details.
[ not to mention all the 'dl' and 'stderr' numa crap ]
With this transfer of the cpu tics duty to our library
the provision associated with the CPU_ZEROTICS #define
could not initially be migrated. The commit referenced
below suggests it may have lost its importance. In any
case such logic may yet be incorporated in the future.
But for now, that #define has been completely removed.
Reference(s):
commit ee3ed4b45e
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit represents the pioneering attempt at using
the concept of 'chained' library requests in an effort
to reduce function call overhead. It required exposing
no more implementation details than were already shown
through the individual calls, yet is satisfied in one.
It is just such an approach that will prove invaluable
when it comes time to access individual /proc/##/data.
Programs could 'chain' only those 'results' structures
representing their current view independent of all the
fields any such programs might be prepared to display.
Thus the standard 'read', which wouldn't apply to task
level data very well (or efficiently), can now become
a 'read_chain' whereby the former PROC_FILL flags need
can be satisfied & yield the minimum open/close calls.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just tweaks top in the following respects:
. for alphabetic integrity, change 'INSP_hdr...' names
. eliminate the -Wsometimes-uninitialized warning that
was found under OSX Yosemite (llvm 6.0/clang-600.0.56)
. update program 'comments' reflecting copyright dates
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the 'b' toggle remains window based (vs. global)
it should no longer require that the window be visible
and either the 'x' or 'y' toggles to be on. Previously
those requirements were intended to remind a user that
there must be something for this command to highlight.
With the introduction of graph modes (specifically the
the bar graph) the 'bold/reverse' toggle has important
implications beyond highlighting some columns or rows.
The %Cpu(s) graph and Mem portion of the memory graphs
are designed to offer a visual clue as to the separate
elements comprising them. But that separation could be
lost under some X color schemes or when top is running
without color (in monochrome mode) and the block graph
is selected. But, if the graph is then changed to bars
any separation always becomes visible whenever the 'b'
toggle is turned off. Portions then show in 'reverse'.
So from now on we'll check nothing, we'll just toggle.
[ Besides, with all the code thrown at restricting a ]
[ 'b' toggle use, it might have all been for naught. ]
[ That toggle could still be set/unset using the 'Z' ]
[ command and the color mapping screen. Geez Louise! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In anticipation of upcoming memory graphing provisions
the abbreviations 'Mem' and 'Swap' are being made into
individual translatable strings in order to be reused.
Additionally, the Mem 'used' amount will now no longer
included the 'buffers' and 'cached' values. Thus, each
Mem category becomes unique. This is the approach used
by tools such as 'htop' or the gnome 'System Monitor'.
Lastly, with that change to the 'used' category it has
been repositioned after 'free' on the Mem & Swap lines
making a comparison between 'total' and 'free' easier.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit extends the top Summary Area cpu states to
include information on Non-Uniform Memory Architecture
nodes. It is based upon changes originally proposed by
Lance Shelton who was instrumental in the final patch.
With this change, the user will have new commands that
will provide alternatives to the individual cpu stats:
. '2' toggles between cpu & numa node summary displays
. '3' provides node summary and related cpu statistics
These extensions required some minimal system support.
Typically, the numactl package (and maybe libnuma-dev)
are all that's needed to show a single node which owns
all the processors. Failing that, or for slightly more
variety, top also offers a #define named PRETEND_NUMA.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
This change represents the extension of user filtering
based on inclusion or exclusion. However where 'U'/'u'
filtering provides an either/or choice, this extension
offers multiple choices applicable to multiple fields.
The 'inclusion' and 'exclusion' criteria can be freely
combined making a powerful tool to fine tune a display
and avoid clutter associated with uninteresting tasks.
I'm convinced it offers unimagined future flexibility!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/top-over-the-top,22http://www.freelists.org/post/procps/top-over-the-top,8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Prior to this commit, top has always taken the easiest
(safest?) approach when dealing with those troublesome
SIGWINCH interrupts. Whenever the user was on a screen
other than the main display, any signal received would
force an immediate exit, returning to the main screen.
With these changes, top will retain the user's current
position regardless of what screen he/she was viewing.
In support the following additional changes were made:
* the initial help screen requires an explicit end key
` not 'any other key' formerly used to request an exit
* the colors mapping screen instructions were improved
* ^Z response was made immediate, eliminating the flag
* the sigaction's SA_RESTART flag had to be eliminated
* sigprocmask logic was normailize to the bare minimum
* the POSIX.1-2004 async-signal safe functions used in
` the signal handlers were acknowledged and documented
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/unwanted-topinspect-window-enclosure-with-the-terminal-size-change
Signed-off-by: Jim Warner <james.warner@comcast.net>
Earlier this year, the switch from KiB to Mib as shown
in top's summary area was postponed to those occasions
when KiB exceeded 8 digits. In hindsight that may have
moved top in the wrong direction, given the difficulty
of digesting such large numbers of digits at a glance.
This commit adds a new 'E' interactive command used to
cycle the displayed memory amounts ranging from KiB to
TiB. Thus, users can choose the radix they wish shown.
p.s. and it will be rcfile preserved for any restarts!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reports
commit 95f2201730
Author: James Cloos <cloos@jhcloos.com>
Date: Mon Feb 6 00:00:00 2012 -0500
Signed-off-by: Jim Warner <james.warner@comcast.net>
When 'type' was added to the alternate status line for
the '=' key, the need for the demonstration 'type' was
overlooked. This commit avoids the '(null)' potential.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s);
commit 3b2b9a95e6
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit extends Inspect provisions for 'find/next'
to each individual selection. Thus a user can maintain
multiple active searches without having to reissue the
locate command whenever the current selection changes.
To emphasize this feature the View screen now displays
the current active locate string or 'N/A' if inactive.
Such a reminder is important when no found matches are
present on the 1st display page, given that they would
otherwise be apparent via the additional highlighting.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit introduces an extremely powerful, flexible
brand new capability. Now, users can pause the normal
iterative display and inspect the contents of any file
or output from any script, command, or even pipelines.
It's invoked via the 'Y' interactive command which, in
turn, is supported with simple user supplied additions
as new entries in the top personal configuration file.
A separate new 'Inspect' window supports scrolling and
searching, similar to the main top display. Except it
extends existing 'L'/'&' (locate/locate-next) commands
so that an out-of-view match automatically adjusts the
horizontal position bringing such data into view. And
it provides for multiple successive same line matches.
Also, the basic 'more/less' navigation keys are active
in this new 'Inspect' window, to ease user transition.
There are no program changes required when entries are
added to or deleted from the rcfile. And there are no
known limits to the complexity of a script, command or
pipeline, other than the unidirectional nature imposed
by the 'popen' function call which top cannot violate.
Since it's impossible to predict exactly what contents
will be generated, top treats all output as raw binary
data. Any control characters display in '^C' notation
while all other unprintable characters show as '<AB>'.
The biggest problem encountered was with the find/next
capability since that strstr guy was really diminished
given the possibility that numerous 'strings' could be
encountered *within* many of top's raw, binary 'rows'.
Oh, and another problem was in maintaining the perfect
left & right text justification of this commit message
along with all of the commit summaries. Some of those
summaries (like this very one) are of course, slightly
shorter, to make room for the 'man document' addition.
Enjoy!
Signed-off-by: Jim Warner <james.warner@comcast.net>
As an aid to the above 2 commands, and as a prelude to
an upcoming 'inspect other output' capability, the act
of selecting a process for either has been simplified.
Positioning a task as the first one displayed, via the
up/down arrow keys, will now establish it as a default
selection for the appropriate command. Thus, that pid
will then be incorporated in a subsequent input prompt.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit accommodates those fields which may have
suffered truncation due to these default limits:
. 5 digits for uid/gid type fields
. 8 characters for user/group type fields
With a new interactive command, users can increase the
width of all such fields, or return to the defaults.
Note:
There are no restrictions on the amount added to
the defaults. The user is free to vastly exceed
screen limits which simply means such fields can
never be displayed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that column headings are independent of column
data format and require no carefully managed padding
bytes they are candidates for nls translation.
This commit migrates all column headings to the .pot
file with additional translator guidance in the form
of maximum sizes to avoid truncation.
It also places these new additions adjacent to their
associated descriptions, which were already present.
Signed-off-by: Jim Warner <james.warner@comcast.net>
At one time, new top silently defaulted when an rcfile
was found to be incompatible. This is exactly what
the old top did. However, after some discussion it
was decided top should alert the user and thereby
save the system administrator some headaches.
Now, some are upset over the fatal error, proving you
can't please everybody. But in all fairness, given
the difficulty of customizing old top, any reluctance
to delete an old saved rcfile is understandable.
To ease transition to this new top, old style rcfiles
will now be honored and converted to the new format.
And if not disabled at ./configure time via CFLAGS,
a user will be warned when an old style rcfile is
about to be overwritten using the 'W' command.
Lastly, the config validation logic was enhanced to
help ensure both types of rcfile haven't been edited
manually and possibly made unuseable.
Reported-By: sergio <mailbox@sergio.spb.ru>
Bug-Debian: http://bugs.debian.org/651213
Reported-By: martin f krafft <madduck@debian.org>
Bug-Debian: http://bugs.debian.org/651863
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit corrects some outdated programmer comments.
Additionally, certain nls justifications might become
increasingly obscure with the passage of time so some
previous nls commit text has been added as comments.
