If there is a PID wrap-around w will choose the wrong process.
For example:
$ ps x -o pgrp,tpgid,start,tty,cmd | grep pts/3
3834 3834 21:50:26 pts/3 ssh server
4461 4461 21:57:14 pts/2 grep pts/3
23410 3834 21:07:17 pts/3 mutt
26071 3834 Jul 13 pts/3 /bin/bash
w will show the user as:
csmall pts/3 my-laptop:S.1 13Jul15 5:54 1.36s 1.13s /bin/bash
So why?
w scans the process table and has two ways of finding the best match.
#1 match things like terminal,username and process group, find oldest
#2 match utmp pid to process tgid
The problem is that #2 trumped #1, which is fine when your login process
is numerically lower than your other processes. However in this case
26071 is larger and appears later in the readdir() than the correct
process, which is 3834.
The fix is not not overwrite best if it already exists.
Signed-off-by: Craig Small <csmall@enc.com.au>
When a user is taking advantage of the scroll features
it is likely a scrolled vertical position is well past
the first displayable task. That is especially true of
top's forest view ('V') mode where those early systemd
attached processes are generally not very interesting.
As such, should the idle mode toggle ('i') be employed
a distorted display is almost guaranteed because tasks
that have used some cpu, and thus should be displayed,
have already been skipped by virtue of their position.
So this patch temporarily nullifies vertical scrolling
during the period when idle tasks are not being shown.
Signed-off-by: Jim Warner <james.warner@comcast.net>
While meminfo does implement only the singular version
of 'xxxx_chain_fill', it was wrong to limit the 'read'
to the plural version (only) within our new slabs API.
This kind of inconsistency will only spell trouble for
future users of the new libprocps API. So, this commit
will mean that any form of xxxx_chain(s)_fill function
also includes a 'read', whereas xxx_getchain does not.
Reference(s):
commit aab537bc13http://www.freelists.org/post/procps/newlib-interfaces
Signed-off-by: Jim Warner <james.warner@comcast.net>
With a little help from smatch, this commit eliminates
some inappropriate code. Also some programmer comments
were (barely) improved (i hope) in some small measure.
Reference(s):
smatch: 406 procps_meminfo_chain_fill() warn: variable dereferenced before check 'chain' (see line 403)
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to exploiting the new interface, a warning
for a meminfo variable 'used uninitialized' was fixed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to the new interface several other changes
were made. In fact, there are so many I must apologize
in advance to Craig, et al. for the hatchet I wielded.
Among the changes was my attempt to shrink the body of
that main() function. It's amazing how some folks must
always cram as code much as possible into ol' main().
Personally, unless it's a throwaway quick & dirty pgm,
all main function bodies should not exceed one screen.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch, we will be close to an implementation
which will be needed when accommodating tasks/threads.
The following explanation was from an earlier message:
The slabtop requirements are similar to those of PIDs.
One must accommodate the variable number of slab nodes
(PIDs) while also accepting different data (char * and
unsigned long). Furthermore, some generalized means to
sort all that acquired stuff must somehow be provided.
------------------------------------------------------
So this patch expands the API to provide dynamic chain
allocation plus allow sorting of those dynamic chains.
While specific to slab needs (nodes, not global stats)
it is not too early to begin to think of newlib chains
as the opaque replacement for a deprecated old proc_t.
Better yet, any newlib chain is inherently variable in
length, something the old proc_t couldn't claim to be.
Of course, as we get to PIDs we'll want to grow/shrink
chains (easily accomplished with a special item enum).
And we'll want to grow/shrink those **head arrays too.
But these minor details don't seem insurmountable now.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit msg summary says it all (well, not really).
The previous statically allocated results chain served
the top program perfectly in all its lib memory needs.
But, someone needs to try out the brand new interface.
Besides, there were a few other changes which I wanted
to make. And among them were the following miscellany:
. some names were changed, like 'context' became 'ctx'
. an unnecessary redundant library call was eliminated
. the placement of a few globals was made more logical
( thanks Craig for following the capitalization rule )
Signed-off-by: Jim Warner <james.warner@comcast.net>
An earlier approach to meminfo chaining, referenced in
the patch shown below, represents the first baby steps
toward the goal of some generalized approach with PIDs
processing. However, statically allocating a chain for
each task or thread is totally impractical. And, while
a single chain could serve all PIDs, that would mean a
separate call to our library for each running process.
This commit is intended as the next evolutionary step,
dynamically allocating some 'result' chains to contain
as many or as few 'items' as a caller wishes. In other
words, holding only those 'items' of current interest.
This is the kind of service useful for both top and ps
programs if we finally get around to /proc/<PID> data.
Reference(s):
commit c3fd7473c5
Signed-off-by: Jim Warner <james.warner@comcast.net>
This was Craig's original patch, referenced below, but
it was never pushed to newlib. It has now been rebased
on top of some diskstat stuff to serve as a beginning.
The original effort was perfectly serviceable (after a
memory leak was fixed) but the approach would not have
served future PID needs when that proc_t went bye bye.
The slabtop requirements are similar to those of PIDs.
One must accommodate the variable number of slab nodes
(PIDs) while also accepting different data (char * and
unsigned long). Furthermore, some generalized means to
sort all that acquired stuff must somehow be provided.
So I wanted to try a different approach that seemed to
hold potential for satisfying future top and ps needs.
Subsequent commits will make that attempt, building on
Craig's original patch whose commit msg appears below.
------------------------------------------------------
All of the /proc/slabinfo related calls have been changed
here. They follow the same procps_slabinfo_* format.
Made both the slabtop and vmstat programs use the new
API as one was using the old one and one was just sort
of trying to do its own thing.
Sorting of slabnodes is also possible via the library.
Reference(s):
http://www.freelists.org/post/procps/Sorting-slabsprocesses,3http://www.freelists.org/post/procps/library-rework-slabinfo-calls
Signed-off-by: Craig Small <csmall@enc.com.au>
Signed-off-by: Jim Warner <james.warner@comcast.net>
The function pid_link tries to handle programs which contain very
long paths to their executables. If 1024 bytes are not enough to
contain the path, the loop wants to get more and more space until
the path can fit.
The loop's condition does not fit though.
readlink will never return a value higher than its supplied size
limit, which is "path_alloc_size - 1", therefore the loop-check of
"len == path_alloc_size" will always be false: the loop will never
be repeated.
While at it, the if-condition inside the loop's body can be omitted,
because it is always true.
malloc and realloc could return NULL when no memory is available.
The code doesn't handle errors, so use xmalloc/xrealloc instead.
While at it, sync alloclen's type with len's type, so both are ssize_t.
The previous commit got rid of some but not all the library. The
format of it was a little odd with the library being explicitly
defined instead of letting autoconf do it for you.
Fixes to option parsing in kill, skill, pkill.
Hi,
These are some fixes to how kill, skill and pkill handle parameters in the -SIGNUM form.
The handling was incorrect in kill/skill, it was actually not properly truncating argc/argv before removing the -SIGNUM argument. There were some hacks around the code to work around the bug, but using `kill -1` on its own would end up working as if `kill -1 -1` (which means `kill -HUP <all processes>`) was executed. (Yes, it was painful when I accidentally typed it... more than once.)
I also made `kill` print the usage if it only gets a signal number, but no pids (as in the `kill -1` example.)
And `pkill` had similar code but was using a buggy atoi() to try to parse the signal number, which meant that trailing garbage was accepted, so I corrected that by removing the buggy atoi() and letting the already existing code that already accepted numeric signals do its work as supposed to...
I also wanted to tackle the "pgrp" case where a negative number is passed to kill, causing it to kill a process group. The current code is buggy, for instance `kill -TERM -2345` will kill process group 2 and not process group 2345 as supposed to. It should also be possible to pass it multiple pgrps or a mix of pgrps and pids. It's hard to fix that though, considering how getopt_long() works, so I'll defer that for a second pull request.
I tested this fairly well, both manually and made sure there were no regressions in the test suite, also didn't break `make distcheck`.
Let me know if you have any questions or other remarks...
Cheers!
Filipe
See merge request !3
This commit prevents pkill from accepting something like `-1garbage` as
a SIGHUP. The previous code was using atoi() which does not check for
trailing garbage and would parse the above as 1.
Handling numeric signals in signal_option() is not really necessary,
since signal_name_to_number() will recognize numeric signals and parse
them properly using strtol() and checking for trailing garbage. It also
checks that the numeric signals are in the proper range. So all we need
to do is remove the buggy numeric signal handling here.
Tested with `pkill -1garbage sleep`, after this patch it will complain
that "1" is not a valid option, which is the expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This makes a command such as `kill -TERM` or `kill -9` fails and prints
usage, instead of silently succeeding.
The behavior is consistent with how `kill` behaves without an explicit
signal, or with the behavior of the `kill` builtin in a shell like bash.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Have skill_sig_option sanitize the command line by properly decrementing
*argc after moving the arguments to remove the -signal one.
One bug caused by this issue was when running `kill -1`, then the code
would interpret -1 as both SIGHUP and as process group -1 and send
SIGHUP to all of them. Or `kill -28` which would send SIGWINCH to
process group -2 (in another bug, the -pgid support only accepts a
single digit, fix for that bug will follow.)
This also reverts commit 7610b3128e ("skill: fix command line with
signal") which worked around this bug in `skill` and also removes the
"sigopt" hack which worked around this bug in `kill`.
The skill_sig_option implementation is compatible with signal_option()
from pgrep.c. I plan to factor them out into a single source file in a
follow up commit, to prevent the duplication.
This commit fixes the issues reported above. I also tested the issues
from commit 7610b3128e, `skill -9 -t pts/0` works as expected, also
tried `kill` with -signal and a number of pids and it worked as
expected.
Also tested that `make check` and `make distcheck` keep working.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
The calls for reading diskstat have been moved out of
sysinfo and into new files diskstat.[ch] These new
library calls follow the standard pattern for the
new libprocps.
vmstat is updated to use the new API and also got
the weighted IO time added.
vmstat -p previously would only show partitions, not
disks. There does not appear to be any good reason to
artifically deny a user to use this command on a disk,
rather than a partition so this restriction was lifted.
I also realised using int for devid means you can send
the library negative numbers, the index uses unsigned int.
Other similiar calls will need to be fixed too.
Signed-off-by: Craig Small <csmall@enc.com.au>
This is actually a systemcall getpagesize(2) or it is defined
in configure using a variety of methods, including a default
hard coded value as a last resort.
There is no need to have this in libprocps
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>
The new library meminfo & vmstat modules use structure
names for their context which exactly mirror the names
of the very /proc/ files whose particulars they yield.
The one exception to this rule was the readstat module
whose struct was named statinfo yet the file was stat.
This commit simply renames that structure (only) so as
to hopefully establish such a naming convention as our
standard going forward. And, it's makes good symmetry.
[ this module's name itself is just perfect as it is ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier attempt at protecting these functions from
already freed memory worked just fine until the memory
was, in fact, reused by the OS. At that point, the ref
count would most likely fail an existing a test for 0.
So this commit will take control of the 'info' pointer
and force it to NULL when a reference count reaches 0.
Plus, since it makes little sense returning an address
that a caller already has, henceforth we will return a
reference count out of the 'ref' and 'unref functions.
Reference(s):
commit 74beff80ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
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>
There was not a way I could see to support top's needs
for cpu information with the new 'chained' provisions.
The sheer quantity of such data plus the unpredictable
number of potential processors suggested a totally new
approach was warranted while keeping internals opaque.
So this patch introduces two new structures solely for
use by potential callers (as seen in the API). They're
responsible for providing them to the library which is
then responsible for filling them with requested data.
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>
Since we are not using a higher level standard C fopen
all of the read requests were made signal sensitive as
that can result in a 'temporarily' failed i/o request.
Also, protection against some user calling the 'unref'
function on already free memory has been incorporated.
This will protect us from some nasty 'Abort' surprise.
Signed-off-by: Jim Warner <james.warner@comcast.net>
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch mostly just eliminates darn tab characters.
Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.
The following names were changed to more closely match
meminfo.c or provide a certain symmetry. Unfortunately
that also impacted some other pgms which were updated.
. 'procps_stat_get' evolved into 'procps_stat_get_sys'
. 'procps_stat_info' is now known as 'procps_statinfo'
[and just a little trailing whitespace was eliminated]
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>
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch fills in some missing fields which have top
dependencies. Additionally, I've tried to mirror those
calculations Jaromir added for release 3.3.10. The one
calculation that remains missing is 'available' memory
for some kernels. For this API, we'll use a fall-back.
Lastly the lxc safeguards which were recently added to
the old procps library were incorporated here as well.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch mostly just eliminates darn tab characters.
Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.
Signed-off-by: Jim Warner <james.warner@comcast.net>
sysctl --system fails when the file /etc/sysctl.conf doesn't
exists. This happens due to wrong check of stat(2) return code.
Reference:
https://www.freelists.org/post/procps/sysctl
Signed-off-by: Craig Small <csmall@enc.com.au>
Created new set of functions for meminfo related calls. Liked the
format of that better so changed vmstat around so the look similar.
Missed the makefile change for uptime so added it in now.
Removed the printf_uptime, binaries can do printf easily enough.
sprint_uptime split into two as there wasn't a lot of common
code
sprint_uptime(): old style uptime line
sprint_uptime_short(): short new style "uptime -p"
Hertz_hack needed this, no sane system uses the code (I think)
so just assume 100 like we do in FreeBSD.
