This patch was made necessary by those library changes
in support of recently revised/simplified wchan logic.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch was made necessary by those library changes
in support of recently revised/simplified wchan logic.
In addition, this commit eliminates a broken alternate
'namelist' provision which was intended to allow users
to specify a System.map file to be used in translating
addresses into function names. But, the real effect of
the now defunct 'N' and '-n' options was to indirectly
force addresses (not names) to be displayed since such
user named map files could not be successfully parsed.
Besides when the required FRAME_POINTER kconfig option
is absent there is no address to translate and when it
is present /proc/PID/wchan is already translated. Thus
an alternate mapping is unnecessary and inappropriate.
[ we'll forgive POSIX for documenting '-n namelist' ]
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
Signed-off-by: Jim Warner <james.warner@comcast.net>
Several Debian based distributions were recently found
to have omitted a kernel configuration option that had
the effect of rendering /proc/#/stat and /proc/#/wchan
useless for providing any 'sleeping in function' info.
That problem also prompted a reevaluation of the whole
approach to wchan matters which had grown increasingly
complex as our library evolved over the last 13 years.
The net result was a decision to rely on /proc/#/wchan
which arrived along with the 2.5 kernel. This then let
us vastly simplify the internal code plus the external
interface which will benefit both the top and ps pgms.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11https://lkml.org/lkml/2008/11/6/12https://bugs.debian.org/711592
Signed-off-by: Jim Warner <james.warner@comcast.net>
It doesn't make any sense to have the binary version strings
embedded into the library. The version strings are defined
already either in the Makefile or in include/c.h
[ in addition to the primary 'lxc' business, i found ]
[ numerous apostrophes used instead of that back-tic ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit adds a lxc container name to every proc_t.
If a process is not running in a container, then a '-'
will be provided, making such a field always sortable.
Unlike other proc_t character pointers, lxc containers
will find many duplicate shared values. So rather than
strdup 'em (with a later free required upon reuse), we
try to keep track of those already seen and share that
address among all tasks running within each container.
We rely on the lines in the task's cgroup subdirectory
which may initially seem somewhat unsophisticated. But
the lxc library itself uses a similar approach when it
is called to list active containers. In that case, the
/proc/net/unix directory is parsed for the '/lxc' eye-
catcher, with potential complications from hashed path
and names that are too long (something we don't face).
[ too bad docker abandoned lxc - our commit won't do ]
[ anything for the users of those kind of containers ]
Reference(s):
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1424253https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1424253
Signed-off-by: Jim Warner <james.warner@comcast.net>
Under a lxc container, the /proc/meminfo 'MemFree' and
'MemAvailable' amounts will be equal, unless memory is
being limited via cgroups in which case 'MemAvailable'
could exceed that for 'MemTotal'. And when a container
has been nested, there exist additional memory quirks.
A program might then display used or available amounts
greater than total memory (assuming unsigned honored),
or negative values (should a signed cast be employed).
This anomaly primarily impacted the top and free pgms.
Thus, two simple sanity checks have been introduced to
avoid any illogical kb_main_available or kb_main_used.
( Busybox top & free also display anomalous although )
( different results when running in a lxc container. )
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153817
Signed-off-by: Jim Warner <james.warner@comcast.net>
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
ps now truncates usernames and doesn't change them to uids.
Man page is now updated with the correct information
Signed-off-by: Craig Small <csmall@enc.com.au>
testsuite would fail if /proc/vmstat was unreadable.
Issue #3 brought up by Mike Frysinger.
test script explicitly checks to see if it is readable and
sets these tests to unsupported if not.
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.
It allows to distinguish the initial NAME (to be translated) with the
latter one (that must not be translated) and thus permits to handle its
translation differently.
References: https://bugs.debian.org/786643
Signed-off-by: Craig Small <csmall@enc.com.au>
Recent commit 9742c74e7c ("pgrep: Enable case-insensitive process matching")
caused the "opts" string to overflow the show 32-character space allocated for
it.
Bump it up to 64 bytes, which should be enough even if more options are added.
Tested: Running ./pgrep stopped crashing and `make check` passed.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
build-sys: use proper dependencies on libproc.la
Use `LDADD` or `*_LDADD` instead of `AM_LDFLAGS` to refer to `libproc.la`.
This is recommended in the automake manual:
http://www.gnu.org/software/automake/manual/html_node/Linking.html
Before this commit, parallel builds may break, as there is no explicit dependency to ensure the library is built before the binaries that try to link to it.
Tested by running `make -jNN` repeatedly for different levels of parallelism to ensure the build works. Also checked that `make check` and `make distcheck` still work as expected. Also made sure that a parallel make invocation works with `make -j distcheck`.
Reported-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
See merge request !2
Use LDADD or *_LDADD instead of AM_LDFLAGS to refer to libproc.la.
Otherwise, parallel builds will break as there is no explicit dependency
to ensure the library is built before the binaries that try to link to
it.
v2: Added empty rules lib_test_*_LDADD to remove the dependency on
libproc which is not used by the lib/test_* binaries.
Tested by running `make -jNN` repeatedly for different levels of
parallelism to ensure the build works. Also checked that `make check`
and `make distcheck` still work as expected. Also made sure that a
parallel make invocation works with `make -j distcheck`.
Reported-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
FreeBSD has case-insensitive matching of processes in pgrep and
pkill, which can be super-useful. This patch uncomments and
documents the code needed to make this work.
Signed-off-by: Craig Small <csmall@enc.com.au>
Updated the documents with the following general changes:
* Replaced Gitorious with GitLab
* Moved translate stuff out of README
* Changed plain text to markdown (looks better on website)
Before this commit, the test checking `vmstat -m` (slabinfo) output uses
a fairly strict regular expression that only allows alphanumeric
characters and a few exceptions such as "_", "-", "(" and ")".
However, recent kernels use a wider range of characters, such as ">".
For instance, see this Linux commit which creates a "page->ptl" slab:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/memory.c?id=b35f1819acd9243a3ff7ad25b1fa8bd6bfe80fb2#n4283
Other patches for reporting slab usage per memcg include the names of
the cgroup in the slabinfo output, which can include additional
characters and use dots for abbreviation.
The check should not be so string, instead it could simply look for a
chain of non-whitespace characters and that should be enough.
Tested that `make check` is still working, including in some of the
environments where features that enable the additional slabinfo names.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Signed-off-by: Craig Small <csmall@enc.com.au>
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>
On most systems the only process with a SID=1 is init
and certainly not a test sleep. On docker systems this
test program IS on SID=1 and so our "impossible SID" becomes
possible.
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.
The "usrbin_execdir" hack meant to install some binaries in /bin and
others in /usr/bin. However:
- It is very inflexible: not much control on the final directory name
and it is not possible to get rid of the usr/bin suffix without
patching the build system.
- It is hard to use: it requires configure to receive --exec_prefix=/
and other settings do not make much sense. It is not very obvious that
that setting needs to be passed and it takes a while to figure it out.
- It produces garbage with the default setup: the default prefix of
/usr/local ends up installing the binaries under /usr/local/usr/bin
which does not make any sense.
Furthermore, the requirement to split binaries in /bin and /usr/bin is
not that strong since some distributions adopted the /usr merge and so
would agree to just deploy all binaries to /usr/bin directly.
Distributions that would still like to split /bin from /usr/bin should
actually move binaries such as `ps` and `kill` to /bin after the install
of procps-ng is complete. After all, they are the ones responsible for
determining what are the binaries that need to be in the root partition
and that list depends on their early boot init scripts, so it is
possible that the list must be augmented with other binaries from this
package.
Therefore, I propose here to get rid of that hack and simply install all
the binaries to bindir instead, which solves the problems described
above and simplifies the build and install of procps-ng.
Tested that it builds and both `make check` and `make distcheck` work.
Tested that `make install` works and produces the expected tree, the
only difference being the absence of the bogus /usr/local/usr/bin
directory and now all binaries are merged into /usr/local/bin as
expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Otherwise, automake 1.14 will warn that this option will become the
default in an upcoming release, which will cause problems for the
procps-ng build.
Now that the automake rules were merged in the top level Makefile.am,
it is possible to enable "subdir-objects" without breaking the build or
the dist.
Tested that it builds and both `make check` and `make distcheck` work.
Tested that `make install` works and produces the same tree before and
after this change. Confirmed that binaries are also placed in the same
locations in the build tree.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
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>
This is cleaner and we need to match paths exactly when we enable the
subdir-objects automake option.
Out-of-tree builds still work since automake is smart to know these are
source files and that it needs to look for them in $(top_srcdir), so
there is no need to make this explicit.
Tested that it builds and both `make check` and `make distcheck` work.
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 suppresses the following warning from libtoolize 2.4.2:
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
Tested that this does not break the build and that both `make check` and
`make distcheck` continue working as expected.
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>
This commit just tweaks top in the following respects:
. for alphabetic integrity, change 'INSP_hdr...' names
. eliminate the -Wsometimes-uninitialized warning that
was found under OSX Yosemite (llvm 6.0/clang-600.0.56)
. update program 'comments' reflecting copyright dates
Signed-off-by: Jim Warner <james.warner@comcast.net>
Free always used 1024 based units but used the confusing old style
kilo,mega etc.
This change changes the names to kibi,mebi for 1024 based divisors
and kilo,mega for 1000 based divisors or IEC units.
It also checks if you try to set two units, e.g free -k -m
Petabyte and Pebibyte have been added.
If you used to use the long options such as --mega these will now
actually print megabytes (they previously printed mebibytes).
The short options are being used on the IEC units
References: https://www.gitorious.org/procps/procps/merge_requests/38
Signed-off-by: Craig Small <csmall@enc.com.au>
The loop that parses options has a of by one bug where the realloc
adds one byte, instead of one list element. This is exposed when
you try things like:
pgrep -t,,,,
Signed-off-by: Craig Small <csmall@enc.com.au>
pgrep got updated due to the confusion of the f,l and a flags.
While the newer behaviour is far better but it is no longer following
the ancient Solaris standards, so that got removed.
References: https://bugs.debian.org/752501
