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
With 99bebff06a a configurable
width of the FROM column was introduced. Unfortunately this
caused a regression in the dash printing. Hopefully fixed
with this commit.
pmap would previously print the process name if
/proc/PID/smaps could be opened, even if subsequent
reads failed. This actually occurs with other users
PIDs.
Kernel 3.18rc1 introduced a change where the file could
not been opened, meaning pmap -X 1 previously showed
the process name and nothing else but NOW shows nothing
make check failed because of this.
This change prints the process name even before trying to open
the file, returning it to previous behaviour.
Thanks to Vincent Bernat for some analysis.
References:
https://bugs.debian.org/775624https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=29a40ace841cba9b661711f042d1821cdc4ad47c
Signed-off-by: Craig Small <csmall@enc.com.au>
When the command is executed in one shot mode (-o) with stdin
being something other than a terminal, the tcgetattr() call
would fail, and generate an error message. e.g.:
slabtop: terminal setting retrieval: Inappropriate ioctl for device
Active / Total Objects (% used) : 905319 / 915886 (98.8%)
Signed-off-by: Craig Small <csmall@enc.com.au>
If skill was used with a signal number then it would intepret
the command line with last option interpreted twice. This often
confused the program so it just would end up killing nothing.
So this would work:
skill -t pts/0
This would not:
skill -9 -t pts/0
The kill path (in the same file) uses the same logic that has
been introduced here.
References: https://www.freelists.org/post/procps/skill-command-does-not-work-in-debian-7-releases
Signed-off-by: Craig Small <csmall@enc.com.au>
A recent commit eliminated the potential for a storage
violation with forest view mode. It occurred when some
program (erroneously?) created a lengthy forking loop.
However, the associated commit message was misleading.
The message implied that an unexpected order following
a sort on start_time was the cause of storage overruns
and a 'char' used to track nesting level only distorts
the display when it goes negative. Actually, the truth
is really just the opposite. Any start_time sort quirk
causes no harm while that 'char' can yield corruption.
Should some child end up sorted ahead of its parent by
way of an extremely unlikely shared start_time the end
result is such a child will be displayed unnested just
like init or kthreadd along with all its own children.
However, if nesting levels exceeded 255 (and became 0)
a massive array overrun could be triggered when such a
task and *all* its children were added to an array for
the second time. Exactly how much storage was violated
depended on the number of children that zeroed process
had spawned (hinted at via either SIGSEGV or SIGABRT).
The earlier commit limited nested levels to 100 so the
root cause of the storage violation was already fixed.
The potential for distorted nesting levels due to sort
on start_time would seem to remain. But it's extremely
unlikely that 2 tasks would share the same start_time.
Even so, a new #define has been introduced which makes
top impervious to the order of tasks such that a qsort
is no longer necessary (providing an init/systemd task
exists & was harvested as the first task by readproc).
It can be utilized if distorted nesting ever becomes a
real issue. But since there is a 5-10% performance hit
with that, we'll continue using start_time as default.
References(s):
commit ce70017eb1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will eliminate a very nasty bug associated
with top's forest view mode. It addresses a potential
SIGSEGV/SIGABRT that was only encountered when another
program (erroneously?) creates a lengthy forking loop.
If the growing list of nested children is sufficiently
fast such that proc_t start_time is duplicated between
children then the sort upon which top relies might not
produce the expected order. That, in turn, could cause
the forest_adds function to initially miss some child.
But that missed child would be caught by forest_create
and eventually would cause our array boundary overrun.
Such overrun occurs when some child of that originally
*missed* child is found and a duplicate add attempted.
In correcting this bug we'll also use this opportunity
to prohibit a borrowed proc_t padding byte (char) from
going negative. If the nesting level exceeded 127, the
effect was an "unnesting" with the snprintf width then
viewed as flag+width also yielding left justification.
Henceforth, we'll limit nesting to 100 with subsequent
children shown as " + ", not the usual " `- " prefix.
References(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153642http://www.freelists.org/post/procps/Bug-in-the-forrest-view,6
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup defaults were changed users with existing
rcfiles would likely find their previous configuration
was not being honored in all respects. The disparities
involved Graphs modes and Summary/Task memory scaling.
This patch simply restores what was always intended as
the proper behavior for previously saved config files.
References(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762928https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762947
. new startup defaults
commit 8ef6cd91fc
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previously the default background color was expected
to be always black and the default foreground color
was expected to be always white. This commit extends
the group of color pairs with pairs containing default
colors.
