Merge request 154 brought up the issue of the space before the commar
after sigaction, however the MR included the translated generated
pages.
References:
procps-ng/procps!154
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Change the default name to cons%d
ctty can be used by other systems not just Cygwin so create a define
separate to cygwin for using the ctty function. The autoconf will need
to be updated to check for these specific systems in future.
Thanks to Achim of the Cygwin project for the patches.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
I'm not sure why you would roll your own macros for major and minor
while the standard includes have these defined. Using our versions
causes two problems:
- Some systems don't use this format for their minor/major
- If the kernel proc interface becomes a 64-bit number, like
dev_t is in the library, then our macro will need to be changed.
autoconf already had the check and as a bonus for anyone that
puts these definitions in sys/mkdev.h it handles that too.
So this is now the standard way of getting a minor/major number out of a
device id. Examining bits/sysmacros.h showed that their defines are
close to what devname.c had, except it can handle 64-bit numbers.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Stops the compilier (correctly) complaining:
lib/test_shm.c: In function ‘main’:
lib/test_shm.c:65:23: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
65 | printf("SHMID: %llx\n", shm_id);
| ~~~^ ~~~~~~
| | |
| | int
| long long unsigned int
shm_id is an int which is what shmget() returns.
Strangely pmap has always scanned this in as a llx even though the maps
"inode" column is the same number that shmget() returns.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Previously the match for shmid was \d+ but the variable is printed
as a hex number, updated the regex to suit.
Added some changes for pmap test so if the test_shm process fails
we just skip past it.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Created a test process test_shm that allocates a shared memory
segment and prints the segment ID. pmap testsuite runs pmap to
check that the segment is found.
The value returned by shmget() is the same value that is printed
in the fifth column /proc/<PID>/maps
Signed-off-by: Craig Small <csmall@dropbear.xyz>
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 Cygwin systems use a different file and format to get the
OS version.
Thanks to procps Cygwin maintainer Achim!
Signed-off-by: Craig Small <csmall@dropbear.xyz>
While the previous commit checked for a GNU environment so Hurd
compilied ok, this tripped up Cygwin. configure now explicitly tests
for the structure field rather than trying to guess through compilier
flags about what the environment tells us about signals.h
References:
commit d39d9db079
Signed-off-by: Craig Small <csmall@dropbear.xyz>
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>
Sometimes due to race conditions or the way dejagnu gates the
output, or even there is another interesting process, the ps tests
sometimes fail. These changes make it a little more lenient without
losing the purpose of the test.
Replaces Debian patch ps_tests
References:
https://salsa.debian.org/debian/procps/-/blob/debian/2%253.3.17-7/debian/patches/ps_checks
In some build systems, such as the Debian pbuilders, the
environment is strange. The tty is called "TTY" which causes
some of the ps tests to fail.
This commit checks for that specific result and returns ""
so the tests can be bypassed.
Replaces Debian patch fix_checks.
References:
https://salsa.debian.org/debian/procps/-/blob/debian/2%253.3.17-7/debian/patches/fix_checks
For some unknown reason, make check doesn't depend on either
the check programs or the actual programs under test. This means
if you try to run make check right off the bat from a clean git
repositorty, it will fail as it won't be able to run the unbuilt
binaries.
I'm not sure why this is needed, but if the dist_man_MANS
variable is not copied from the top-level Makefile down to the
man-po one then make dist from a clean archive will not work.
I'm sure someone with better automake magic than me can make
this more elegant but for now it works if a little ugly.
References:
https://www.freelists.org/post/procps/important-newlib-patches,8
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>
This started off with fixing the compilier warning:
proc/readproc.c: In function ‘simple_nextpid’:
proc/readproc.c:1373:38: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 58 [-Wformat-truncation=]
1373 | snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
| ^~
proc/readproc.c:1373:3: note: ‘snprintf’ output between 7 and 262 bytes into a destination of size 64
1373 | snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We know that ent->d_name will fit under 64 bytes because we check the
name starts with a digit. The first change was simple and changed the
printf to use tgid like the task function below it.
Is everything under /proc that starts with a digit a directory with a
PID only? Today, it is but there are no guarantees.
The entire function works ok if every non-pid directory doesn't start
with a number. We don't check for strtoul() having an issue nor
if the for loop just falls off the end. The moment the kernel guys
(or some module writer) think "/proc/12mykernelval" is a neat idea this
function is in trouble. We won't get buffer overflow as we are
using snprintf at least.
This change now:
We check if strtoul() actually came across a number
Process the pid directory as a conditional branch
Treat falling off the for loop as a not-found
Signed-off-by: Craig Small <csmall@dropbear.xyz>
/usr/include/x86_64-linux-gnu/bits/error.h:40:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
40 | __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pmap.c: In function ‘main’:
pmap.c:760:35: note: format string is defined here
760 | xerrx(EXIT_FAILURE, "%s: '%s'", _("failed to parse argument"), optarg);
A simple check for optarg being null silenced this, not sure why only
this one was a problem.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The procfs mount option subset=pid only shows the processes, not things
such as /proc/stat etc.
For certain programs, this should mean they still work, but have reduced
functionality. This is the first cut at some of them.
pgrep - Removed always loading uptime which we never used anyway. The
program now works fine unless we use --older. Add note in man page
stating it will silently fail.
ps - Load boot time and memory total only when required instead of
always. Changed the error messages to something the user actually
cares about "can't get system boot time" vs "create a structure".
Works for most fields except starts and percent memory.
uptime - Give more useful error messages if uptime not available.
vmstat - move header generation after testing for required proc
files, makes the default output more consistent with the rest
of the options.
References:
procps-ng/procps#227https://www.kernel.org/doc/html/latest/filesystems/proc.html#chapter-4-configuring-procfshttps://github.com/torvalds/linux/commit/6814ef2d992af09451bbeda4770daa204461329e
Signed-off-by: Craig Small <csmall@dropbear.xyz>
While the kernel calls the fields pgpgin and pgpgout, the units
here are not pages, but KiB (or 2x 512 sectors).
The comments come from the referenced merged request, this commit fixes
the "vmstat -s lies" part:
https://elixir.bootlin.com/linux/v5.15-rc7/source/block/blk-core.c#L1057
has submit_bio() which includes the count_vm_events(PGPGIN, count) but what
is count? it is usually what bio_sectors() returns.
bio_sectors() is a macro in
https://elixir.bootlin.com/linux/v5.15-rc7/source/include/linux/bio.h#L49
that defines that as bio->bi_iter.bi_size >> 9. 2^9 is 512 or the sector
size. So our count is incremented by the number of 512-byte sectors.
As @dublio has already pointed out before this result is printed to vmstat,
it is /= 2 to give the number of kibibytes (as the sectors were 512 bytes,
we now made the block size 2*512 or 1024). The code even has
"sectors -> kbytes".
So unless there is something very strange going on, pgpgin and pgpgout in
/proc/vmstat return kibibytes.
What about pages (which is sort of implied in the name) or blocks (as
described on the man page)?
Pages can vary, but they are generally 4 KiB so they're out. That also means
vmstat -s lies :(
Blocks are harder to discount. While these too can vary, they can be 1 KiB;
they could also be something else (e.g dd its 512, filesystems 4096).
However, for memory management inside the kernel, there are sectors and
there are (near userland export) KiB, nothing else. It's probably more
accurate to say sectors are shifted in and out of block devices and the
kernel expresses these transfers to userland as KiB by halving the numbers.
What all this means is that using KiB for bi/bo aka pgpgin/pgpgout is more
accurate than saying blocks or pages.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!64
upminutes and uphours could both not get initialised in the
procps_uptime_sprint_short() function.
Error was probably introduced at the referenced commit.
References:
Coverity 240787 Uninitialized scalar variable
Coverity 240776 Uninitialized scalar variable
commit 0496b39876
Signed-off-by: Craig Small <csmall@dropbear.xyz>
do_regcomp() error message didn't use a string literal for the format string.
pgrep.c:538:24: error: format not a string literal and no format arguments
[-Werror=format-security]
Signed-off-by: Craig Small <csmall@dropbear.xyz>
99126 Explicit null dereferenced
Not 100% sure this is valid (the same branch that sets the variable
is the one that sets N_option) but not too hard to fix.
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>
procps fails to build from source due to usage of field si_int of struct
siginfo_t in lib/test_process.c which does not exist on GNU/Hurd.
Thanks to Svante Signell for the patch.
References:
https://bugs.debian.org/987557
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>
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>
This is a modification of MR !122 by @renit1609 to fit the new
library.
Problem statement:
The procps library has no PROC_FILLIO flag to
fetch the proc field "/proc/[pid]/io" data
process-wise.
IO Accounting is not included as part of procps.
Requirement:
We have a requirement to fetch process wise
IO utilization which can be used for monitoring.
When looking through the procps library, I see
that IO Accounting (/proc/[pid]/io) is not being
included as part of procps. There is no such
flag like PROC_FILLIO being included in readproc.h .
Solution:
While looking at the implementation done for
other proc fields, I used the spare bits in app code.
I renamed PROC_SPARE_1 as PROC_FILLIO, the spare bit from
PROC_SPARE_* and used it for fetching /proc/[pid]/io
data as part of the procps library similar to other
fields. I moved the PROC_SPARE_* bits each by 1 bit
to retain the spare bits. Meanwhile added the IO fields
in proc_t structure.
References:
procps-ng/procps!122procps-ng/procps#184
The correct long option for -w is --no-wrap but the man page
said it was --no-linewrap
References:
procps-ng/procps#203
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>
vmstat -d testsuite will fail if your /proc/diskstats is present
but zero length. While this seems buggy behaviour from lxcfs, its
there and its a simple matter to test for it and skip those tests
if we are run on a zero length /proc/diskstats system.
The ps.1 manpage incorrectly stated that psr field showed the
processor the process was assigned to. However if the assignment
has changed but the process has not run, then the field doesn't
change.
Some digging by @srikard showed it wasn't the processor assigned
but the last one it was run on. The man page now correctly
describes psr in that way.
References:
procps-ng/procps#187
The sysctl.8 manpage explained the directory order but not that the
files were then ordered and run in lexiographic order no matter
the directory name.
References:
procps-ng/procps#200
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
@ruihongw quite rightly pointed out we removed the l option
from the man page and getopt but the iunreachable case statement
remained.
References:
commit 94468ac0b3#162
Signed-off-by: Craig Small <csmall@dropbear.xyz>
If automake doesn't see a dist_man_MANS then there is no
uninstall-man target. This fix uses the main Makefile
targets.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
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>
Sometimes the testing sequence would leave a source tree
under procps-ng-(version) which, if update-potfiles was
run, would include these temporary files in the list, causing issues
later.
The script now explicitly ignores those temporary files.
I'm not sure if anyone actually uses these things, but if you
selected test fields on the command line ps would crash.
$ ps/pscommand -o _left
Signal 11 (SEGV) caught by pscommand (3.3.11.877-0488).
/home/csmall/Projects/procps/procps/ps/.libs/pscommand:ps/display.c:66: please report this bug
Segmentation fault
Anyway, it doesn't now:
$ ps/pscommand -o pid,_left,_left2,_right,_unlimited 1
PID LLLLLLLL L2L2L2L2 RRRRRRRRRRR U
1 tty7 3270/tty4 59:59 [123456789-12345] <defunct>
This is part of !118 where @tt.rantala found a memory leak.
The other part of !118 may come later if the performance change
is significant.
References:
procps-ng/procps!118
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
noinst_PROGRAMS are built with "make" even though we had the
test programs in there and only needed them for "make check".
In theory the check target should depend on check_PROGRAMS as
check-am target does and the document states it should, but for
reasons understood by the automake whisperers only, it doesn't
build them.
check only depends on BUILT_SOURCES for some reason.
check-am: all-am
$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
$(MAKE) $(AM_MAKEFLAGS) check-TESTS
check: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) check-recursive
References:
https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
The referenced commits created the library infrastructure and test
program to validate that the structures and macros line up with
each other.
The library needs to be (re)built with -DITEMTABLE_DEBUG and then
the test program ran. We clean before and after so we are not
testing a non-debug library or having a debug library hanging around
to cause future problems.
Due to test_Itemtables depending on the library, we don't need to
explicitly build the library.
To validate the library structure/header corrospondence run:
make check-lib
References:
commit e616409aa4
commit 92d0297e1ehttps://www.freelists.org/post/procps/keep-on-patchin,19
Craig Small