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>
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 866abacf88
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>
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
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!125procps-ng/procps#190
When the p/e-cores support (via the '5' key) was added
in the patch referenced below, I intentionally omitted
that key from the top primary help screen. This seemed
appropriate since it only applied to select Intel cpus
and, besides, that screen was getting kind of crowded.
[ it remains an objective to fit on a 80x24 terminal ]
Upon reflection, I found a way to squeeze it into that
help screen and have decided to included it. Hopefully
its presence will encourage use of top's new provision
on any Intel platforms that distinguish between cores.
Reference(s):
Sep, 2022 - exploit p/e-cores provision
commit 00f5c74b1b
Signed-off-by: Jim Warner <james.warner@comcast.net>
vmstat <n> would update most fields, but the memory statistics
were only fetched the first time.
References:
https://bugs.debian.org/1027963
Signed-off-by: Craig Small <csmall@dropbear.xyz>
procps 3.3.17 the c option changed the command/args field
to cmd but this got removed as part of newlib
Functionality is back in with a test case.
References:
https://bugs.debian.org/1026326
Signed-off-by: Craig Small <csmall@dropbear.xyz>
When the skill program was ported to the new API the code to filter
on PID, used by the -p option, was missed. It is now restored.
References:
https://bugs.debian.org/1025915
Thanks to @kabe-gl for this patch.
w command shows ????? for LOGIN@ column when compiled on 32bit environment with -D_TIME_BITS=64.
References:
#256
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Tracking what we do to the library so the N:N:N version strings are
updated. This is just a NEWS item for previous commit.
References:
commit b89e3230b2
If procps is built on a Linux 5.3+ system then pidwait
is built with pidfd_open(). If that program is run on
a system < 5.3 then it gives an odd generic error.
If we get a ENOSYS from one pid, we will get it for all
the others so its better to explain what happens and terminate.
The man page is updated to note this issue.
This came up due to killall in psmisc using pidfd_send_signal
References:
https://bugs.debian.org/1015228
Signed-off-by: Craig Small <csmall@dropbear.xyz>
[ along the way, we'll fix-up the section 4 commands ]
[ summary which has gotten a little outdated lately. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ along the way we will restore '^R' to keys summary ]
[ plus correct a leftover reference to 'Ctrl-V' too. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
pmap uses freopen to read /proc/self/maps. There doesn't
seem to be a good reason to do this and if pmap has its
stdin previously closed then it fails.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
On occasion, even as the top author, I wonder why that
'x' toggle has stopped working. Of course, it actually
was working but a locate request ('L') or other filter
('O') operation was active and thus temporarily turned
if off. Such behavior is documented in top's man page.
Well, with this patch that 'x' suppression is no more.
[ the original justification, however, remains true. ]
[ but there's really only one character which causes ]
[ any potential trouble & i'm gonna' keep it secret. ]
[ besides, if a display is corrupted, there's always ]
[ that '=' key which restores things back to normal. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
As a result of the issue referenced below, we'll trade
our homegrown offset generator for an 'offsetof' macro
found in the stddef.h header file. This pleases clang.
[ and thanks to Daniel Kolesa for the report and fix ]
Reference(s):
. bug report & recommended solution
https://gitlab.com/procps-ng/procps/-/issues/235
. clang error message
proc/readproc.c:673:9: error: initializer element is not a compile-time constant
mkENT(Rss),
^~~~~~~~~~
proc/readproc.c:661:34: note: expanded from macro 'mkENT'
#define mkENT(F) { #F ":", -1, (int)((void*)&q->smap_ ## F - (void*)&q->fZERO) }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the globbing update was put into sysctl, you could no longer
simply use the keys because one key could potentially be
multiple paths once the glob expansion occured. Using the path
instead gave a unique output.
Except certain programs, such as salt, expected the output to use
the dotted path "kernel.hostname" and not "kernel/hostname".
We can no longer use the original key, so now for each path:
Copy the path
strip off /proc/
convert all / to .
The sysctl testsuite was also updated to check for a few different
types of conversion failures.
References:
commit 6389deca5bhttps://www.freelists.org/post/procps/some-procpsn4400-fixes,4https://repo.saltproject.io/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
[ i also tweaked that 'STARTED' narrative just a bit ]
[ since its original wording implied the value could ]
[ change, whereas it's fixed when a task is started. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit used the value from mbstowcs() to work out
the spacing required, as printf() got it completely wrong.
However, for alignment of text you don't use the string length
but the string width.
As the referenced website says:
Use wcslen when allocating memory for wide characters, and use wcswidth to
align text.
Which is what free does now. Chinese is still off by one but I cannot
see why this is so. It's close enough for now. If someone can work
it out, I'd love to know what the fix is.
As a side effect, #213 is fixed because we are putting the correct
number of spaces in.
French is still an issue (see #24 ) but this is because the string is
too long!
References:
procps-ng/procps#24procps-ng/procps#213procps-ng/procps#229
commit 9f4db0fb56https://www.linux.com/news/programming-wide-characters/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
free has for many years had a problem with translated header columns
or the first column. This is because printf("-9s", str) doesn't use
the wide length of the string but the char length meaning they are
mis-aligned.
Using the mbstowcs() function to get the wide length and then
a precision parameter to append the right number of spaces after the
number means we get what we need.
References:
procps-ng/procps#229procps-ng/procps#204procps-ng/procps#206https://bugs.debian.org/1001689
Signed-off-by: Craig Small <csmall@dropbear.xyz>
You can match or filter on cgroup paths. Currently the match is only
done for version 2 cgroups because these are way simpler as they have
a unified name and always start with "0::".
cgroup v1 can have:
named groups "1:name=myspecialname:"
controllers "9:blkio:"
multiple controllers! "4:cpu,cpuacct:"
So they are very much more complicated from a options parsing and
cgroup matching point of view.
In addition, both my Debian bookworm and bullseye systems use
v2 cgroups.
$ ./pgrep --cgroup /system.slice/cron.service
760
Signed-off-by: Craig Small <csmall@dropbear.xyz>
