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>
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>
This commit is just preparing for adding an Itemtables
verification test by reorganizing stuff and activating
a few previously inactive (overlooked?) test programs.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The referenced commits enavled both pkill and kill to send an integer to
the killed or signalled process. The test_process now will report on the
integer if sent and the testsuite changes take advantage of this
new feature.
Another process make/destroy set had to be made as using spawn
instead of exec changes both the SID and TTY for the underlying
process, making other tests fail.
References:
commit 7d55409b82
commit 2b804a532a
When writing to procfs via `proc_write` fails, we try to chunk the
buffer into smaller pieces to work around that issue. When searching for
the next location to split the buffer, though, we can underflow the
buffer in case the current offset is smaller than `LINELEN`. Fix the
issue by passing `cookie->offset` instead of `LINELEN` into `memrchr` in
case `cookie->offset` is smaller than `LINELEN`.
This bug can be triggered on musl-based systems, e.g. by executing
$ sysctl kernel.printk_ratelimit=1000000000000000
As the value is out-of-range, `write` will return an error and set
`errno` to `EINVAL`. As we're only trying to write a smallish buffer
with a length smaller than `LINELEN` and as the buffer does not contain
any newlines, the call
token = (char*)memrchr(cookie->buf+offset, '\n', LINELEN);
will underflow the buffer and crash the program.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
The `fprocopen` function allows users to specify a delimiter chacter
that is used to split very large input lines into smaller chunks. While
the code checks that the caller did actually supply the delimiter, it is
in fact never used to split the string. Instead, the hardcoded default
character ',' is always used to split the string.
Fix the issue by using `cookie->delim` instead.
And signal_name_to_number().
---------------------------- adapted for newlib branch
. file has been moved to: lib/signals.c
. only 'signal_name_to_number()' was impacted
. function 'print_given_signals()' no longer exists
. thus the bulk of original patch no longer applicable
Signed-off-by: Jim Warner <james.warner@comcast.net>
Do not memleak "copy" in case of an error.
Do not use "sizeof(converted)" in snprintf(), since "converted" is a
"char *" (luckily, 8 >= sizeof(char *)). Also, remove "sizeof(char)"
which is guaranteed to be 1 by the C standard, and replace 8 with 12,
which is enough to hold any stringified int and does not consume more
memory (in both cases, the glibc malloc()ates a minimum-sized chunk).
---------------------------- adapted for newlib branch
. no longer in library, logic now found in lib/signals.c
. craig already addressed "copy" memleak in commit beloww
Reference(s):
commit d2df396ba9
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.
The only essential change was substituting 'comma' for
the word 'colon' in the man page plus program comment.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Duplicate that <libio.h> change made in master branch.
While we're at it, let's remove an unnecessary include
from procio.h and reflect in its single prototype what
those 'const char *' params are really supposed to be.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the procio logic was removed from the library
we must move the header file, lest we break make dist.
In the process, we will relocate that source file too.
[ we'll take a slightly different approach than that ]
[ used under the master branch by exploiting those 2 ]
[ non-library directories 'include' and 'lib', while ]
[ avoiding any sysctl hard coded function prototype. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the value of number_of_signals is known at compile time, we can
use a compile-time check instead. This also adds SIGLOST for the Hurd,
uses the correct signal counts for the Hurd and FreeBSD, and only gives
a compile-time warning when compiled on an unknown platform that it does
not know whether the number of signals is correct.
Author: James Clarke <jrtc27@jrtc27.com>
References:
commit bd72ba3a4b (jrtc27/procps-cross-platform)
procps-ng/procps~!52
This was supposed to be just a cherry-pick of the referenced
commit. However there were two problems:
1. kill code was moved out to its own file
2. strtosig() had a latent bug where signal numbers were not
converted to names.
Original note:
kill -lHUP would work correctly, but kill -l HUP would not.
The list option in kill was hit by a quirk of getopt_long where an
option with an optional argument would not attempt to get the argument
beyond the space, even though a mandatory argument would do that.
The fix is a kludge to scan to the next argument and if it looks
like something we can use, use it. Lucky for us, the list option is
one where parsing can stop immediately.
Thanks to Brian Vandenberg for the way forward.
References:
http://stackoverflow.com/questions/1052746/getopt-does-not-parse-optional-arguments-to-parametershttps://bugs.debian.org/854407
commit 537cea324b121f54744369425332c256aa84a181
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]
proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]
ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]
watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
Signed-off-by: Jim Warner <james.warner@comcast.net>
kill -l SIGHUP (or any other signal-name prefixed with "SIG")
would cause free() to be called with a bad pointer instead of
a pointer to what was allocated. Fix this and add test-case.
FreeBSD doesn't have SIGPWR so makes no sense in warning and assuming
its 29.
Picked from master, but the file has moved from proc/sig.c to
library/signals.c
References:
commit 8abd0c92abhttps://bugs.debian/org/832148
Signed-off-by: Craig Small <csmall@enc.com.au>
There is a need in some utilities to have a way of accepting both
types of decimal points "." and ",". The only way seems to be to
rebuild strtod().
This new function will accept "123.456" and "123,456" as 123.456
and considers them the same number. It means we lose thousands
separator, but this is rarely used.
test scripts are added to check the function returns the proper
values. There was simpler predecessor that got stuck on negative
0 or -0.123 which these tests flushed out.
References:
The first part of fixing skill/snice to use the library instead
of directly readdir()ing /proc which is what it does now.
Remove the kill code from the skill/snice code and put common
elements into lib/signals.c Not 100% sure that is the right
destination instead of a new lib file, but ok for now.
kill shares some parsing logic with skill/snice but mainly
around signal specifications. The "do it" code is very different.
Signed-off-by: Craig Small <csmall@enc.com.au>
Functions related to namespaces were half-in half-out of the
procps library and didn't fit the standard naming scheme.
While struct { long ns[x]} is a bit clunky, its the only way
to "lock in" x. The alternative is to use ns_* variables.
This work was needed before pgrep could be converted.
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
For the test suite, procps used to use sleep which would just
create a process or two to test the tools against. Some setups
coreutils creates all programs including sleep into one blob which
means a lot of the tests fail, see issue #2
procps has its own sleep program now.
This will be required for subdir-objects, otherwise automake will have
problems with more than one Makefile.am having rules to build the same
files.
Tested that it builds and both `make check` and `make distcheck` work.
Tested `make install` and compared the tree with the one installed
before this commit, both installed the binaries to the same locations.
The binaries are also in the same location in the build tree (for
instance, ps/pscommand is still there.)
Checked the binaries for the correct libraries linked into them. Binary
sizes matched before and after this change.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
In order to avoid compiling the same source files twice, with and
without the TEST_PROGRAM define.
Tested that the build still works and that `make distcheck` works as
expected.
Tested that the test_* programs in lib/ keep working. (Though they are
not really invoked by `make check` and in particular test_nsutils is
quite useless, test_fileutils also quite poor.)
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is required for out-of-tree build to work, since many source files
include e.g. proc/*.h which is not under the include/ directory.
Tested that `make distcheck` starts working after this patch.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
The previous commit removes the stdio_ext.h header,
but the ns_read function calls snprintf that needs
stdio.h and therefore moving the stdio.h include
from the bottom test program to the top line.
The <stdio_ext.h> include breaks building on platforms without that header and is unused in nsutils.c.
Also remove unused but harmless <error.h> include.
The translated manpage generation has moved from scripts to
Makefiles. This asists with conditional building as well, no
need to regenerate the German pgrep man page if both
the original pgrep.1 and man-po/de.po is not changed.
My Makefile-fu fails me on producing a cross-product or double
iteration for languages and man pages. Until that is solved
each man page is explicitly built. No big deal but it doesn't
look elegant in the Makefile. Languages will be picked
up automatically if they are found in man-po, man-po/top or
man-po/ps
The README describes the three-step process for translating
the files, incase I forget or someone else wants to update them.
When fileutils with stream error checking was borrowed
from GNU lib, an omission was also propagated where an
errno of EPIPE wouldn't be preserved in close_stream()
making a test for EPIPE in close_stdout() meaningless.
This patch corrects such oversight so that an errno of
EPIPE no longer produces 'write error' at program end.
( gnulib provides for optionally ignoring EPIPE, but )
( if a program chooses to ignore it, then their code )
( appears to suffer from this close_stream oversight )
Reference(s):
. original fileutilis addition
commit c7cf98b0e0
. bugzilla report
https://bugzilla.redhat.com/show_bug.cgi?id=976199
A PID should be specified with --ns:
$ pgrep --ns 12345
which will only match the processes which belong to to the same 6
namespaces. It is also possible to specify which namespaces to test:
$ pgrep --ns 12345 --nslist mnt,net,ipc
which will match processes that belong to the same mount, network and
IPC namespaces as PID 12345.
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
For portability, check for error.h during configure and define
HAVE_ERROR_H accordingly.
If this header is not available, emulate the functionality of error()
from glibc with an inline wrapper in include/c.h.
For portability, check for stdio_ext.h during configure and define
HAVE_STDIO_EXT_H accordingly.
If the current system does not provide this header, use a fallback for
__fpending(). This definition will not work on all systems as it relies
on internal data structures of libc. A more portable solution should be
preferred, for example by using gnulib.
The entire tree's polluted with inappropriate trailing
whitespace. This commit rids our environment of all of
those useless keystrokes. Unfortunately, it sure ain't
a permanent solution and requires every contributor to
instruct their editor(s) to prevent or eliminate them.
Plus it's strongly recommended we all insert something
like what's shown below to our '.gitconfig' file so as
to provide at least some warnings when we try to apply
any patches (git am) that do contain the #@!%& things!
References(s):
~/.gitconfig excerpt ---------------------------------
[core]
whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
whitespace = warn
--------------------------------- ~/.gitconfig excerpt
Signed-off-by: Jim Warner <james.warner@comcast.net>
./lib/fileutils.c:9:5: warning: no previous declaration for 'close_stream' [-Wmissing-declarations]
./lib/fileutils.c:23:6: warning: no previous declaration for 'close_stdout' [-Wmissing-declarations]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Even as conservative project as coreutils has switched to xz distributions so
neither should we have any reason to use gz and waste space & bandwidth.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
err and warn are BSD format but they are not recommended by library
developers. However their consiseness is useful!
The solution is to use some macros that create xerr etc which then
just map to the error() function. The next problem is error() uses
program_invocation_name so we set this to program_invovation_short_name
This is a global set but seems to be the convention (or at least errors
are on the short name only) used everywhere else.
