Library systemd-login offers possibility to display the Unix
user identifier of the owner of the session of a process.
This information will also be displayed for user processes which
are shared between multiple login sessions of the same user,
where sd_session will be blank.
This patch adds output option "sd_ouid" which will show
user UID or "-", when there is no owner for a process.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
Library systemd-login offers possibility to display name
of login session for specific pid.
Note that not all processes are part of a login session
(e.g. system service processes, user processes that are shared
between multiple sessions of the same user, or kernel threads).
This patch adds output option "sd_session" which will
show name of session or "-", when process does not belong
to any session.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
Library systemd-login offers possibility to display
name of a systemd unit file for specific pid. Note that
not all processes are part of a system unit/service
(e.g. user processes, or kernel threads).
This patch adds output option "sd_unit" which will
show name of systemd unit or "-", when process does not
belong to any unit.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
One recent patch to dynamic buffer management involved
over-allocating the buffer increase to lessen calls to
xrealloc. That was successful, but the actual increase
amount did not attempt to optimize size or alignments.
With this commit, we'll copy an approach recently used
by the top program and round up buffer sizes to 1 KiB.
More importantly, while buffers are quickly reaching a
KiB optimum multiple, no memcpy will ever be employed!
To illustrate just how effective top's algorithm would
be, just change the initial and subsequent allocations
from the current 1024 bytes to just a single byte then
add an fprintf. Those one byte reallocations while on
the way to optimum buffer size will be a one-time cost
and won't represent any recurring performance penalty.
( gosh, that top program *must be* one fart smeller, )
( or was that a smart feller, i can't remember which )
Reference)s):
commit 6d605f521c
commit a45dace4b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Almost forever, top has been accessing the /proc/stat/
directory one line at a time until either smp_num_cpus
was reached or (more recently) Screen_rows is reached.
When NUMA/Nodes support is enabled screen rows will no
longer serve as a limit because all cpus must be read.
With this commit, the entire /proc/stat/ directory can
be read at once so all statistics will be frozen. Thus
individual cpus will no longer keep "ticing" until top
gets around to accessing them via some separate fgets.
The distortion this commit eliminates was quite easily
seen when comparing old/new tops using: individual cpu
stats vs. cpu summary; a healthy delay interval of 3-5
seconds; manually synchronized update cycles (the hard
part); some system loading (maybe another top at -d0).
Additionally, this patch eliminates some long standing
unnecessary initialization made possible because of an
allocation via calloc. If some parts are never touched
by sscanf due to a kernel version, it's unnecessary to
repeatedly re-initialize those portions to zero again.
Reference(s):
. numa extensions added
commit 8d989c68c0
. useless initialization evolution (old to new)
commit e54c8239b1
commit 9278134e49
commit fd62123562
commit f348575edc
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the addition of NUMA/Node support and the ability
to emulate such support even in the absence of libnuma
and numa.h, the maximum number of cpus top can emulate
was increased to make numa emulation more interesting.
( whew, that's an awful lot of "emulates", me thinks )
Reference(s):
commit 8d989c68c0
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the same fashion of pgrep, introduce two new options:
--ns <pid>
- nslist <ns,...>
which allows processes to be filtered by namespace.
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
A PID should be specified with --ns:
$ pgrep --ns 12345
which will only match the processes which belong to to the same 6
namespaces. It is also possible to specify which namespaces to test:
$ pgrep --ns 12345 --nslist mnt,net,ipc
which will match processes that belong to the same mount, network and
IPC namespaces as PID 12345.
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
Each process in Linux has a /proc/<pid>/ns directory which contains
symbolic links to pipes that identify which namespaces that process
belongs to. This patch adds support for ps to display that information
optionally.
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
This patch provides the build system support for those
top extensions dealing with the NUMA summary displays.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(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>
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 commit provides the NEWS and man document changes
supporting the new NUMA/Node top program enhancements.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(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 patch provides the build system support for those
top extensions dealing with the NUMA summary displays.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(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>
The change in pmap is necessary if it happens that the whole output of
pmap -X or -XX has been done before the second regexp is matched. Since
the matching is greedy, it is matched by the full output, so that
nothing is left for the third regexp and the test fails with
FAIL: extra extended output (footer).
Reference: http://comments.gmane.org/gmane.linux.lfs.devel/13961
Signed-off-by: Craig Small <csmall@enc.com.au>
An earlier commit attempted to cleanse our environment
of all useless trailing whitespace. But the effort did
not catch 'empty' lines with a single space before ^J.
This commit hopefully finishes off the earlier effort.
In the meantime, let's pray that contributors' editors
are configured so that such wasted crap is disallowed!
Reference(s):
commit fe75e26ab6
Signed-off-by: Jim Warner <james.warner@comcast.net>
When utility buffers were introduced for file2str read
requests, a subtle change was inadvertently introduced
such that a read of zero no longer returns a -1 value.
This commit ensures that zero bytes read returns a -1.
And although the solution differs from a merge request
submitted by sergey.senozhatsky@gmail.com, a thank you
is offered for revealing this potential abend problem.
References(s):
commit a45dace4b8http://gitorious.org/procps/procps/merge_requests/11
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Craig Small <csmall@enc.com.au>
When dynamic buffers were recently introduced for read
of the status, stat and statm subdirectories one extra
call to read() was required for end-of-file detection.
This patch avoids most all such extra calls to read().
Additionally, the frequency of memory reallocations is
reduced by overallocating each increase more than 25%.
Reference)s):
commit a45dace4b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Craig Small <csmall@enc.com.au>
Gilles brought up a warning message in sysctl.c
sysctl.c: In function 'main':
sysctl.c:767: warning: value computed is not used
The return value of Preload was not being applied correctly to ret
meaning sysctl would not return the correct value.
Reference: http://www.freelists.org/post/procps/procpsng-337,18
Signed-off-by: Craig Small <csmall@enc.com.au>
Internal changes to libproc means the revision number
is incremented. This does not mean an ABI or API change has
occured, we just do the stuff under the covers better or in this
case reduce the compile warnings mainly.
See Jim, I do read the commit messages :)
pmap.c: In function 'one_proc':
pmap.c:529: warning: 'maxw1' may be used uninitialized in this function
pmap.c:529: warning: 'maxw2' may be used uninitialized in this function
pmap.c:529: warning: 'maxw3' may be used uninitialized in this function
pmap.c:529: warning: 'maxw4' may be used uninitialized in this function
pmap.c:529: warning: 'maxw5' may be used uninitialized in this function
Without -d and -x option, that should be doable to trigger the issue but I haven't found how
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
pmap.c: In function 'print_extended_maps':
pmap.c:310: warning: unused variable 'value'
pmap.c: In function 'config_read':
pmap.c:792: warning: unused variable 'section'
pmap.c: In function 'get_default_rc_filename':
pmap.c:969: warning: unused variable 'ret'
pmap.c: In function 'main':
pmap.c:999: warning: unused variable 'default_rc_filename'
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
readproc.c: In function 'stat2proc' :
readproc.c:516: warning: use of assignment suppression and length modifier together in gnu_scanf format
readproc.c:516: warning: use of assignment suppression and length modifier together in gnu_scanf format
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
When 'Other Filtering' was introduced the idea of what
constituted a displayed row changed. No longer was any
call to task_show assured of consuming one screen row.
Now the determining factor was whether or not the rows
were empty. This worked Ok until a certain Find string
was active then the entire display could be corrupted.
With Find active, the task_show() function alters each
returned row while highlighting each visible match. If
the search was on a single byte value & matched at the
beginning of a row the match got overwritten with '\0'
which then appears empty upon return to window_show().
So that row would not be counted as having been shown.
This was best illustrated with a Find on a single ' '.
This patch will restore proper 'Find/Locate' behavior.
Reference(s):
commit 5edc6fb317
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent Debian bug report, dealing with release 3.2.8
and its even more restrictive buffer sizes (1024) used
in stat, statm and status reads via file2str calls, is
a reminder of what could yet happen to procps-ng. Size
needs are determined by kernel evolution and/or config
options so that bug could resurface even though buffer
size is currently 4 times the old procps-3.2.8 limits.
Those sizes were raised from 1024 to 4096 bytes in the
patch submitted by Eric Dumazet, and referenced below.
This patch makes libprocps immune to future changes in
the amount of stuff that is ultimately found in a proc
'stat', 'statm' or 'status' subdirectory. We now trade
the former static buffer of 4096 bytes for dynamically
allocated buffers whose size can be increased by need.
Even though this change is solely an internal one, and
in no way directly affects the API or the ABI, libtool
suggests that the LIBprocps_REVISION be raised. I hope
Craig remembers to do that just before a next release.
We don't want a repeat of the procps-ng-3.3.4 boo-boo,
but with no API/ABI impact that probably can't happen.
p.s. A big thanks to Jaromir Capik <jcapik@redhat.com>
who reviewed my original version and, of course, found
some of my trademark illogic + unnecessary code. After
his coaxing, he helped make this a much better commit.
Reference(s):
. procps-3.2.8
http://bugs.debian.org/702965
. allow large list of groups
commit 7933435584
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reviewed by: Jaromir Capik <jcapik@redhat.com>
If the 'Inspect' feature was used to view a file which
contained binary (unprintable) data, and when the last
line for such a file was purely unprintable, then that
line length would be overstated by the terminal width.
This was also the occasion where valgrind might object
over potential reference to some unitialized value(s).
It was a harmless situation and somewhat rare to begin
with. Anyway this commit will eliminate the potential.
Additionally, supporting readfile logic was simplified
and the 'status line' bytes read is now more accurate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some recent nls work on that pmap program necessitated
a return to nls translation file creation for testing.
As it turns out, my skills used in pseudo-translations
had become rusty and some newer LC_MESSAGE directories
may have been introduced since last needing the topic.
This patch just updates some programmer notes to agree
with this most recent effort and for future reference!
Reference(s):
. pmap nls support
commit 0c0c543466
Signed-off-by: Jim Warner <james.warner@comcast.net>
For portability, check for error.h during configure and define
HAVE_ERROR_H accordingly.
If this header is not available, emulate the functionality of error()
from glibc with an inline wrapper in include/c.h.
For portability, check for stdio_ext.h during configure and define
HAVE_STDIO_EXT_H accordingly.
If the current system does not provide this header, use a fallback for
__fpending(). This definition will not work on all systems as it relies
on internal data structures of libc. A more portable solution should be
preferred, for example by using gnulib.
For portabiliy, check for program_invocation_name during configure and
define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is
now enclosed with the appropriate #ifdef block.
The symbol program_invocation_name is only used for error message
handling using error(), so it's safe to omit this if it is not
available.
This commit fixes the width measurement of the extended pmap
function to work correctly with the -q switch. With no header
and no footer only widths of the particular values matter.
For some reason when the new -X/-XX options were added
what was always displayed as 'Mode' became 'Flags'. So
now a precious horizontal space is wasted because that
field's data has only 4 bytes whereas the header is 5.
Moreover, this created a conflict with the top program
which used that name in a column header already. Plus,
top emitted a 'Translation Hint' that suggests the max
chars should be 8 which is a limit pmap needn't share!
The xgettext program provides no way to keep identical
strings separate. This meant both top and pmap will be
sharing not only the msgid but a Translation Hint too.
So, the solution will now be two distinct field names.
Besides the kernel folks document it as 'perm' anyway!
Reference(s):
new options for pmap
commit faec340719
Signed-off-by: Jim Warner <james.warner@comcast.net>
The existing gettext nls support in pmap exposed users
to some potentially ugly misalignments should the text
that's used in headers someday actually be translated.
The length issue had been addressed already for -X/-XX
modes, but the column headers weren't nls translatable
as yet. This commit makes any header (not literally in
/proc/#/smaps) nls aware. It provides translated width
protection to all modes except one that's header-less!
As part of this effort, the occasional two spaces that
preceeded the Mapping column have been reduced to one.
Reference(s):
new usage & fix coding style
commit d50884788d
improve translations
commit 0022b6ec5d
add gettext support
commit d59cf08c9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the new -X/-XX options were introduced, the width
and justification requirements were satisfied with a 2
step approach. First, format strings would dynamically
be built and then employed in the subsequent printf().
This was a total waste of time and resources since the
printf family of functions provide for the '*' width &
precision conventions to meet this need via arguments.
But even more importantly that foolish endeavor always
hides the potential warnings like the one shown below.
Henceforth this pmap will printf in the proper manner!
Reference(s):
new options for pmap
commit faec340719
pmap.c:459:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just adjusts miscellaneous indentation etc.
so we can begin the odious task of addressing the pmap
nls needs with at least a consistently formatted base.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ever since pmap was refactored via the reference below
(and sprinkled with those damn tabs), the response for
the absence of any argument has been an error message.
This patch restores the proper behavior ('usage' text)
and updates the dejagnu 'no arguments' expect pattern.
Reference(s):
commit d50884788d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit introduces 4 new switches for the RC support
and 1 more switch for toggling the path printing
in the mapping field. the configuration file can be used
for a selection of columns to be displayed and for toggling
the path printing in the mapping field.
This commit increases the upper limit of permitted values
in the expect_table_dsc procedure from 999,999 to 99,999,999.
The previous value was insufficient and causing the slabtop test
to fail on build systems where the number of objects exceeds
one milion.
The entire tree's polluted with inappropriate trailing
whitespace. This commit rids our environment of all of
those useless keystrokes. Unfortunately, it sure ain't
a permanent solution and requires every contributor to
instruct their editor(s) to prevent or eliminate them.
Plus it's strongly recommended we all insert something
like what's shown below to our '.gitconfig' file so as
to provide at least some warnings when we try to apply
any patches (git am) that do contain the #@!%& things!
References(s):
~/.gitconfig excerpt ---------------------------------
[core]
whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
whitespace = warn
--------------------------------- ~/.gitconfig excerpt
Signed-off-by: Jim Warner <james.warner@comcast.net>
There is a member of the osel_s structure called 'flg'
that is used to reflect whether a particular filter is
one of inclusion or exclusion (negation). So by golly,
from now on we'll refer to it as 'inc', and not 'flg'!
Signed-off-by: Jim Warner <james.warner@comcast.net>
