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>
This MR revisits a partial fix from 2018. The problem stems from incorrect
handling of unsigned 32-bit uid_ts and gid_ts as signed when values are
large - i.e. when the high bit is set. In that case, pgrep and pkill fail to
identify processes by uid. (They succeed when finding the same processes by
username.) The primary fix for this is to impliment the "FIXME" comment in
proc/readproc.h, the implementation of which allows the removal of the (int)
casts from the partial fix from 2018.
The other fixed code in this MR consists of tests in strict_atol() that
detects and errors out on overflows.
References:
Merge !146
uptime -p would show empty output after 52 weeks of uptime. This commit
is largely the work of Ed but reformatted for newlib branch.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!141procps-ng/procps#217
Real usecase:
'sysctl -w user.max_uts_namespaces=2147483648; echo $?'
returns 0 even though it failed with EINVAL
The close_stream() realised there was an issue and printed an
error but didn't change the return value.
Slightly modified merge request.
References:
procps-ng/procps!76
Signed-off-by: Craig Small <csmall@dropbear.xyz>
systemd-sysctl handles glob patterns along with overrides and
exceptions. Now the procps sysctl does it too.
The return value for sysctl is consistently either 0 or 1.
Added tests to check sysctl functions.
References:
procps-ng/procps#191
Signed-off-by: Craig Small <csmall@dropbear.xyz>
These changes were already implemented for this newlib
version, but not in the the master branch top version.
[ and we also add the missing 3.3.17 ps 'exe' change ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
sysctl would try to read/write any path you gave it either on
the command line or configuration file. It would append /proc/sys
on the path but not check for any sneaky path traversal with ../
This commit means it first resolves all paths using realpath(3)
and then checks the path starts with "/proc/sys/"
At first I thought this might be a non-issue, but perhaps someone
could put a file into the sysctl configuration path and.. do
something? Anyway its a 8-line fix and makes things more correct.
References:
#179
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The library added smaps_rollup fields in the referenced commit.
This commit exploits the new fields to give pss and uss options.
These options were first proposed back in 2015 by Petr Malat
and, with the library update, they are finally made it into ps.
Why use proportional or unique segment size? It is argued that
these give a better idea of the "real" memory usage of a process.
References:
commit 12543b6c76
issue #112https://www.freelists.org/post/procps/PSS-and-USS-support-for-pshttps://lwn.net/Articles/230975/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The pgrep code checks to see if the program is run as pkill or pidwait
and changes its behaviour accordingly. Some older versions of libtool
run the programs as lt-pkill and lt-pidwait which means the tests fail.
We add these two program names to the checks.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
If you run slabtop with the -d option and then -o option the
delay gets set to zero and it runs forever. slabtop now checks
for this combination and errors.
Adding a DEJAGNU test also found that none of the slabtop
checks were running so they got added to the list and only the
ones that need /proc/slabinfo (if not readable) are skipped.
References:
#160
What to call the new library?
Keep using libprocps wouldn't do, its a very different library from
the programs' point of view. It would also mean we could have some
clashes around the packages (two package names, same library name).
The ancient procps used libproc or libproc-a.b.c where a.b.c was the
package version. Kept the revision numbers down (it was always 0.0.0)
but the name of the library changed.
So if we use libproc-2 is there a clash with an ancient procps?
procps v 2.0.0 was around in 1999 so it was 22 years ago, also the
name of the library would have been libproc-2.0.0.so not libproc-2.so
so we're fine with that.
libproc-2 seems to fit, our second major re-work of the procps
library.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
While sysctl did change the order of /run and /etc to match
systemd in the referenced commit, the Debian bug report that
brought it to light was not documented.
References:
commit 24a1574f0ahttps://bugs.debian.org/950788
free, slabtop and uptime would happily take extra command line
arguments and doing nothing about them. The programs now check
optind after option processing and will give you usage screen
if there is anything extra.
References:
procps-ng/procps#181
For long lines from a process, watch would wrap them around to the
next. While this default option has it uses, sometimes you want to
just cut those long lines down.
watch has a -w flag which will truncate the lines to the number
of columns. A few simple lines to do this new trick.
I think I caught all the ANSI state correctly but there might be
a chance it bleeds to the next row.
References:
procps-ng/procps#182
The referenced commit the comm length was increased from 16 to 64
characters to handle the larger command names for things like kernel
threads.
However most user processes are limited to 15 characters which means
if you try something like ps -C myprogramisbiggerthansixteen this would
fail to match because /proc/<PID>/comm would only be myprogramisbigg
ps now checks the comm length and if it is 15 and if the given match
is 15 or more, it will only match the first 15 characters.
This is also how killall has worked for about a year.
Thanks to Jean Delvare <jdelvare@suse.de> for the note.
Copy of commit from master.
References:
commit 14005a371e
commit psmisc/psmisc@1188315cd0
commit 3e1c00d051
Signed-off-by: Craig Small <csmall@dropbear.xyz>
This patch fixes a nearly decade old bug discovered by
Frederik Deweerdt. His merge request shown below would
be an adequate solution except for iterative overhead.
This alternate patch will represent substantially less
overhead for an admittedly extremely rare possibility.
Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/114
And-thanks-to: Frederik Deweerdt <fdeweerdt@fastly.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
