| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
terminfo is notoriously unreliable when it comes to the
erase character. Use the terminal setting instead. Also
hardcode both commonly used characters just to be safe.
Do not assign unwanted actions to '\0'.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/278
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While musl has utmpx.h, their header file does not define all the
values, especially __UT_HOSTSIZE and friends. Instead it just
hard codes the sizes :/
This change will look for that definition specifically and if
not found will include utmp.h too. Checked on Alpine 3.17
musl just makes these a stub so w doesn't work anyway.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the cpu utilization is displayed for
the first time, the reading of the /proc/stat
file is very close to each other, resulting
in large fluctuations. The version before
refactoring, such as v3.3.17, has a delay
before reading the /proc/stat file for the
second time, and the same delay is added here.
signed-off-by: zhoujie <zhoujie133@huawei.com>
signed-off-by: he jingxian <hejingxian@huawei.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This program employs fixed size stacks which currently
total 85 result structures. When a field was not being
shown, those unused result structures were initialized
as 'PIDS_extra' items. As a result, that library would
then reset the results to zero with every interaction.
For any of those result structs holding values created
by top this was appropriate. But for most, it was not.
So this patch will reduce that use of PIDS_extra while
vastly increasing use of the less expensive PIDS_noop.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, all the newlib APIs handle the assigning of
results the same. Namely, they loop through the stacks
while checking for the hidden 'logical_end' fencepost.
Along the way, the Item_table was indexed to determine
which 'setsfunc' to call, passing suitable parameters.
The approach was quite robust since by testing against
the unsigned 'logical_end' enumerator this library was
immune from user result corruption. The worst that may
happen was early loop exit with some results unvalued.
However, there was a drawback to the current approach.
For every result structure in every stack, an index to
that Item_table had to be calculated for a 'setsfunc'.
For programs like top or ps that may involve thousands
of Item_table index recalculations for each iteration.
With this commit, in support of assign, we will now do
the needed Item_table calculations just one time under
the 'new' and 'reset' functions. Then, at assign time,
the only overhead is actually invoking the 'setsfunc'.
This makes us even more robust than we were before. No
longer will a corrupted results structure suffer early
assign exit leaving some unvalued. Rather, all results
are properly placed regardless of any user corruption.
[ those other interfaces will remain unchanged since ]
[ the depth of their stacks are modest and since the ]
[ assign guys weren't already passed an info pointer ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ever since this pids api was first introduced in 2015,
there existed both the 'curitems' plus 'maxitems' used
internally. While the reasoning behind such duality is
lost to time, it probably related to top's capacity to
grow/shrink stack size depending on what is displayed.
While top no longer employs a dynamically sized stack,
with the current library logic it makes no difference.
For sometime now the pids guy handles either approach.
So, this commit converts all references to 'maxitems'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
| |
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added the -L --line option to free to show a small
set of memory statistics on a single line of 80 characters.
Largely based on the work of @Ulenrich1 and updated to
the new API.
References:
procps-ng/procps#156
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
| |
Rather than attempt to convert usec to sec with division, add both
together and then divide.
This reduced the rounding errors on my system.
|
| |
|
|
|
|
| |
Ref: https://bugs.debian.org/1033477
Ref: https://lore.kernel.org/linux-man/7818bd3c-0351-a738-fd69-14b59838cbeb@gmail.com/t/#u
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of our physical machine shows that the "CACHE SIZE" column
of slabtop output is extremely high, three times of the products
of objs nums and objs size. After some analysis, we found that
the order of slab, which decides "pages per slab", will shrink
when memory pressure is high and normal order allocation failed.
So we think it might help to add these comments to the man help.
Minor fix: add the "memory." back, which is lost after
"aa461df0: docs: Minor manpage fixes"
Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
|
| |
|
|
|
|
|
|
|
|
| |
The 'guest' tics are added in the
sum_tics function, but when multiple
cpus are combined for display, the
'guest' tics are not added cumulatively
in the sum_unify function.
signed-off-by: zhoujie <zhoujie133@huawei.com>
|
| |
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
| |
The utmp format of glibc is not Y2038 safe, not even on 64bit systems.
Query logind/elogind for the number of users if we use libsystemd.
Signed-off-by: Thorsten Kukuk <kukuk@suse.com>
|
| |
|
|
|
| |
References:
issue procps-ng/procps#271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Well this is embarrassing. After repeatedly flogging a
horse (represented by issue #274) I was certain it was
dead. But, it turns out that the darn thing yet lived.
In fact, the bug that was patched was not even the one
the poster experienced. Now merge request #173 finally
penetrated my foggy brain and explicated the real bug.
Since forever (linux 2.6), top has ignored those guest
and guest_nice fields in /proc/stat. When many virtual
machines were running that overhead went unrecognized.
So, this commit simply adds those tics to the 'system'
figures so that it can be seen in text or graph modes.
Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/173
https://gitlab.com/procps-ng/procps/-/issues/274
. Mar 2023, avoid keystroke '%Cpu' distortions
commit 7e33fc47c642aceea8ad53e86a6797239b91f5f9
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Please do not look at this change and especially don't
look at that commit message for the patch shown below.
[ that way you won't notice I misinterpreted 'H' for ]
[ an 'h' when this logic was reversed as 'redundant' ]
Reference(s):
commit 7e33fc47c642aceea8ad53e86a6797239b91f5f9
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like a line from the movie Cool Hand Luke: "what we've
got here is failure to communicate"; well that was me!
Finally, I got a handle on the issue referenced below.
At first, it seemed inappropriate to try comparing cpu
percentages as reported by different top versions. And
even more so when they are invoked many seconds apart.
As it turns out, this issue had nothing to do with the
specific processor. Nor did it involve two versions of
top running simultaneously using the same delay value.
Rather, it concerns keyboard input and several changes
which were made last year in commits referenced below.
They were prompted by development of the 'Ctrl' bottom
window feature. Initially, if transitioning from a big
window to a small window portions of the former window
remained visible until the next refresh. A solution to
that led to a flaw when resizing top. Fixing that then
created a race condition with full screen replacement.
The net effect of all those changes was to distort the
cpu percentage value for the processor on which top is
dispatched to service user input. It arose because the
new frame was begun immediately, yielding few 'ticks'.
[ when fewer ticks are accumulated the potential for ]
[ distortion increases. As an example, hold some key ]
[ then watch cpu percentages (works best in graphs). ]
[ while any version of top will show distortions for ]
[ the above experiment, a v4.0.0 top will be greater ]
[ and %cpu is distorted even for a single keystroke. ]
So, to restore proper 3.3.17 keystroke behavior, we'll
revert parts of the first 3 commits shown below. Plus,
the 4th commit will be entirely reversed as redundant.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/274
. Sep, 2022 - avoid potential 'BREAK_screen' race
commit 3e5016c2898d7129d2cdae7b1def8fe85d41619f
. Sep, 2022 - fix improper sigwinch behavior
commit 9d9993708b1854f7396b978a6d54d6c508e1fd08
. May, 2022 - made more responsive to kdb input
commit 3ea1bc779fb7ca5bf065a5ca620ec5b5823bc61c
. turn bottom window off with additional key
commit 3f068a66c84347a42fd27d8a809cea2656043b37
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When getopt usage was added (plus long options) in the
patch shown below, top no longer returned EXIT_FAILURE
when the error message was generated by getopt itself.
This commit will restore the proper behavior no matter
who might issue a command line argument error message.
Thanks to Bastian Bittorf for discovering this buglet.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/273
. sep, 2021 - getopt with long form args
commit c91b371485b7ffaea3a7c669b080328d141dfb6b
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
| |
strncpy does not null terminate a string if it has the maximal length.
Use always the null terminated variants for ut_user and ut_line.
Signed-off-by: Thorsten Kukuk <kukuk@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the issue referenced below, it is now apparent that
not all architectures follow a logical/expected format
for the /proc/cpuinfo file. Specifically, the expected
empty line after each processor entry might be missing
under some architectures for the last processor shown.
[ and a belated review of kernel source confirms it. ]
So this commit makes our stat module a little bit more
tolerant of some potential missing newline characters.
[ along the way, it's also now tolerant of a missing ]
[ cpuinfo file plus more efficient whenever a cpu is ]
[ is not linked to a core or toggled offline/online. ]
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/272
procps-ng/procps#272
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pgrep was used to match on signal, it makes sense to use
the same signal parsing code as pkill. Unfortunately the
"find the signal" part is a little too enthusaistic about what a
signal is, meaning
pgrep -u -42
fails because the signal becomes "42" and then there is no UID.
This is a bit sad for pkill but has been that way for a long
time. For pgrep this is new so now only the long form
pgrep --signal <X>
will work.
In addition, when using --signal if pgrep/pkill couldn't work
out what the signal was it just silently ignored it. It now
complains and aborts.
References:
https://bugs.debian.org/1031765
commit 866abacf8805a74fb7c59cae1f64963e0a540b14
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comparing floats with == is bad and I should feel bad I did this.
The problem is if something is close to, but not quite the exact
same fails tests.
I have used an epsilon of 1 because we don't care about accuracy,
just that the function works well enough.
References:
issue procps-ng/procps#271
https://how-to.fandom.com/wiki/Howto_compare_floating_point_numbers_in_the_C_programming_language
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| | |
|
| |
|
|
|
|
|
|
| |
E.g. on my system I see this output to "free -vh", which fails the test:
total used free shared buff/cache available
Mem: 23Gi 17Gi 311Mi 2.2Gi 8.1Gi 5.8Gi
Swap: 2.0Gi 1.9Gi 105Mi
Comm: 13Gi 44Gi -31Gi
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit just tweaks some recent copyright changes.
Foe example, the six public header files are unique to
this new library and thus are just attributed to Craig
and me. Plus, there were some misnamed file references
as '.c' for '.h' or 'libprocps' instead of 'libproc2'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
| |
Fixed the Swedish man-po file too
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
| |
Giving them all a standard format and using either the existing
header or the git logs to put the relevant authors in.
|
| |
|
|
|
|
|
| |
This patch just follows Craig's lead for the remaining
ps and top program files and associated man documents.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
| |
The copyrights of the source files were all out of date and were not
the same format. This has been corrected. The source of the authors
was examining the git log for each file.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
In some cases the --terminal option to pgrep will cause all processes
matching the terminal to be output, even if other criteria would exclude them.
Specifically, I noticed that it overrides the --runstates option.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With the commit shown below a BOT_PRESENT constant was
introduced. Unfortunately it was defined in a way that
disable ^L (message log) and ^P (namespaces) highlight
when using the tab key. This patch fixes such an oops.
Reference(s):
. Jan, 2023 - lessen 'bottom window' overhead
commit 28f44729dab9b292a9d5499f8cad6a12c1eb4ae5
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lstart field has been converted to use the strftime()
function so that it uses the locale. A new option -D
allows the user to define the format that would want this
field to show.
This may mean the field will be longer than it should be,
especially for French locales and the user defined field,
but the field length can be specified too.
---
This commit started off making all the relevant fields use the
locale correctly so it could solve #226 as well. The issue
is there an implied restriction (or not) around
strftime("%b") and probably strftime("%a") for abbrievated month
and day names respectively.
English, and some/most other languages put an additional
restriction that all abbreviations are 3 characters long.
The problem is, not all languages do this.
French is a good example:
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Maybe strip the . at the end?
That helps for some months, not all
Maybe take the first three characters?
Several wide languages will have big issues
Maybe convert wide, get wcslen then use that.
Even after that June "juin" and July "juil" are both "jui".
So, anything that uses the month (bsdstart,start) use ctime which
doesn't use locale. That solves the length issue.
stime does, which means it has this issue but its been like that
for years. You get stuff like this:
janv.13 482261
00:00 1151918
2022 1458628
06:12 1957584
The only way to fix that would be to
a)Make the field two characters longer
b)Convert it back to ctime() which means everyone else
loses.
This could have be oh-so easy if everyone made %b and %a three
(wide) characters everywhere.
References:
procps-ng/procps#228
procps-ng/procps#226
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
| |
Made it follow the standard format and removed some cruft.
Added notes about you do need special permissions for some things
such as slabs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix conversion errors due to precision issues in function unitConvert
For example: unitConvert(98720620) will return 98720624, not 98720620.
Because we do (unsigned long)(float)98720620 in function unitConvert
and this is wrong! We should do (unsigned long)(double)98720620 here.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!75
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the default display option, the first line of stats output in the
above mentioned columns was incorrect.
References:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668580
procps-ng/procps!74
procps-ng/procps#15
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.
Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.
After some fiddling around, the exact problematic behavior appears to be
as follows:
1. Lines which would have wrapped (more than $COLUMNS chars long) are
handled correctly.
2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
printed; but then the next line is *not* printed! For long sequences
of non-wrap-length lines, you get an every-other-line-is-visible
sort of effect.
The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.
However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.
Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.
References:
procps-ng/procps!157
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
| |
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.
References:
procps-ng/procps!125
procps-ng/procps#190
|
| |
|
|
|
|
|
|
| |
Based upon merge request 104, closes #174
References:
procps-ng/procps!104
procps-ng/procps#174
|
| |
|
|
|
| |
References:
procps-ng/procps#230
|
| |
|
|
|
|
|
|
|
|
| |
Updated the definition of total, because its not *all* of
the installed memory but close to it.
References:
procps-ng/procps#247
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
| |
References:
procps-ng/procps#263
|
| |
|
|
|
| |
References:
procps-ng/procps!156
|
