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>
Reverted the translation hint as the fields are used for both
normal and wide modes, so need to fit the smaller of the two.
Added NEWS item
References:
commit 01c1b2345e
Based on the command line option, use 'sigqueue'
instead of 'kill' to pass the integer value with
the signal.
References:
procps-ng/procps!32
Signed-off-by: Craig Small <csmall@dropbear.xyz>
With the two preceding 'catch up' patches, this newlib
NEWS can now be made identical to that master version.
[ it's assumed any releases prior to 3.3.15 have all ]
[ been represented under newlib (where appropriate). ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
sig.c had this odd logic where on non-Hurd systems it would undefine
SIGLOST. Fine for Hurd or amd64 Linux systems. Bad for a sparc which
has SIGLOST defined *and* is not Hurd.
Just check its defined, its much simpler.
--------------- Original Master Branch Commit Message:
Some non-glibc systems didn't have libio.h or __BEGIN_DECLS
Changes to make it more standard.
References:
issue #88
Signed-off-by: Jim Warner <james.warner@comcast.net>
