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>
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
The previous commit had one minor bug in it because the fields need
to be alphabetical and times comes after timeout.
Added NEWS item for this feature
Added another testsuite check for new flags in case they
disappear or go strange one day.
References:
commit 8a94ed6111
On some setups the signals count can change and be truncated. You
will notice this because the number will have "<" prepended. The
testsuite didn't handle this.
You could either get:
BLOCKED BLOCKED BLOCKED CAUGHT
CAUGHT CATCHED
0000000000000000 0000000000000000 0000000000000000 00000001f3d1fef9 00000001f3d1fef9 00000001f3d1fef9
or
BLOCKED BLOCKED BLOCKED CAUGHT CAUGHT CATCHED
00000000 00000000 00000000 <f3d1fef9 <f3d1fef9 <f3d1fef9
The current regexp checks for a \s+ in the beginning, however that will
only match if there is a \n in the `ps` output before test-schedbatch,
but that will not happen if test-schedbatch is the first process in the
list, which happens if the PID of test-schedbatch is low enough to bring
it up in the sorted list.
Fix it by enabling newline-sensitive matching with (?n) which then
allows using ^ and $ anchors in the regexp (including an optional \r
introduced by expect.) Matching the end of line also improves checking
that the last field matches 18 exactly and not something like 181, etc.
Tested that `make check` does not break and also fixed the flakiness
seen in an environment with few processes running under the test user
which made the issue more frequent.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Signed-off-by: Craig Small <csmall@enc.com.au>
Right now the test case is both testing it (expect_pass "$test") and
marking it as untested (untested "$test"), it should do either one or
the other, so stop marking it as untested.
Before this change, these lines appear in testsuite/ps.log or the output
of `make check RUNTESTFLAGS="--all"`:
PASS: ps SCHED_BATCH scheduler
UNTESTED: ps SCHED_BATCH scheduler
Note that the second line is confusing, it's implying that the test is
untested, right after having tested it and indicated it passes.
After this change, only the first line will appear.
Tested that both `make check` and `make distcheck` continue working with
this commit.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Signed-off-by: Craig Small <csmall@enc.com.au>
The ps sched test has been disabled. There are too many
odd build farms this fails in strange ways.
Other odd build farms have no tty and so some tests check
for no tty and skip if not found.
Fix the build where it seems a code fix for Linux was likely untested
on other systems.
Define SCHED_BATCH in test-schedbatch, for systems that don't have it;
the corresponding RH BZ#741090 patch used the magic value 3 in output.c
anyway.
Bug-Debian: http://bugs.debian.org/677055
