In their 3.2.7 version of top, Redhat introduced an -M
switch to automatically scale Summary Area memory data
to avoid truncation (and the resulting '+' indicator).
The procps-ng top does not employ suffixes with memory
data nor does it allow for different scaling with each
separate value. Rather, scaling appears at line start.
If built without ./configure --disable-modern-top, the
Summary Area memory will be scaled at GiB which should
lessen chance of truncation. Otherwise KiB was used to
reflect such memory, increasing the truncation chance.
And while 'W' can be used to preserve some appropriate
scaling value, there are arguments against such rcfile
approaches as cited in the issue and bug report below.
So this commit will bump the Summary Area memory scale
factor from KiB to MiB when using --disable-modern-top
as a concession to that Redhat bug report noted below.
And it also introduces a new command line switch which
can force any desired scaling regardless of the rcfile
or which ./configure option might have been specified.
[ for top's help text we'll show 'E' as if it were a ]
[ switch without arguments in order to keep the help ]
[ text displayable without wrap in an 80x24 terminal ]
[ the man page, however, will show all k-e arguments ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/53https://bugzilla.redhat.com/show_bug.cgi?id=1034466
[ this patch has been adapted from the master branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
After much reflection I've come to the conclusion that
displaying 3 decimal places (usually) when memory data
had been scaled is no longer optimal with today's ever
increasing amounts. And given that not all task memory
fields are the same widths, inconsistencies can easily
arise as illustrated and discussed in the issue below.
Instead of unilaterally reducing the number of decimal
places, this commit will sneak in such a change via an
existing configure option that was very likely unused.
The former 'disable-wide-memory' option has now become
'enable-wide-memory', which can be used if the current
behavior (3 decimal places) is preferred. Without that
option, whenever memory is scaled beyond KiB, just one
decimal place will be shown in Summary and Task areas.
And Task area field width will no longer be changed by
this revised configure option. Instead, all such field
widths will now be fixed at the former maximum values.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/50
[ this patch has been adapted from the master branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Original report:
When trying kill a process with insufficient privileges (see blow),
pkill displays the error message “... failed: Operation not permitted”,
but returns 0. Surely it should return 3?
$ pkill syslogd ; echo $?
pkill: killing pid 373 failed: Operation not permitted
0
Return value 0 means one of more things matched. For a pgrep (which
shares code with pkill) this makes sense, there was a match. It seems
wrong for pkill to return 0 when it in fact could not do what you told
it to. However return value 3 means a fatal error and it's not fatal.
Looking at other programs when trying to kill things it cannot kill.
shell kill returns 1, procps kill returns 1, killall returns 1, skill
returns 0 (and says it was successful!, ah well poor old skill)
The consensus seems to be that you return 1 if you cannot kill it, even
if you found it. In other words the return value for both not found and
not able to kill it is the same.
pkill only returns 0 if something was killed. This means we found a
match AND the kill() system call worked too.
References:
https://bugs.debian.org/852758
Signed-off-by: Craig Small <csmall@enc.com.au>
This commit will resolve the RedHat Bugzilla #1322111.
[ import from identical commit against master branch ]
[ but without trailing whitespace, thank you so much ]
Imported by: Jim Warner <james.warner@comcast.net>
While a Debian bug report referenced below was limited
to the 'eip' and 'esp' fields, this patch also extends
address width adaptations to some other addresses too.
[ and, we do so in a far less invasive manner than a ]
[ redhat approach shown below adding two new fields! ]
Reference(s):
. new debian bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846361
. old redhat solution
https://bugzilla.redhat.com/show_bug.cgi?id=244152
Signed-off-by: Jim Warner <james.warner@comcast.net>
This just brings the newlib branch NEWS into line with
the current version from our master branch since those
changes have already been incorporated in this branch.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Both watch and free used the locale to determine the required delay
interval for subsequent updates. It's preferable to not care about
locale and accept both 12.34 and 12,34 as meaning 12 seconds and
340 microseconds.
References:
https://bugs.debian.org/692113
Signed-off-by: Craig Small <csmall@enc.com.au>
The procps library attempts to work out the tty of a process
through several methods. For things like /dev/tty123 or
/dev/foo it works fine.
For tty devices that put the minor number in a directory
of the major name this fails. So then we have to fallback
to stating things like the processes STDERR and try again.
Considering a lot of processes sit on ttys such as
/dev/pts/3 this is a lot of wasted time. At the point of
entering driver_name we know "/dev/pts" and we know "3"
we just didn't join them up the right way as this is old
code.
This change now looks for /dev/pts/3 as well. It does it
after looking for /dev/pts3 so the behaviour is the same.
References:
https://bugs.debian.org/770215
Signed-off-by: Craig Small <csmall@enc.com.au>
Shell kill would report a problem if you tried to kill a process
while procps kill was silent. This meant it looked like kill worked
when it actually failed.
References:
commit 07642b8ea6https://bugs.debian.org/733172
A difference in behaviour between the sysvinit and procps pidof
was that the procps one would sometimes not find process that
the sysvinit one did.
The difference is that if a space is found in argv[0] then sysvinit
would look at cmd for a match. This isn't perfect and more of a
best guess but does often work.
procps pidof now follows the same "standard". The most obvious
difference is with kde based processes and incoming ssh connections
with sshd.
References:
Commit 3f5b75035e
GitLab issue #4https://gitlab.com/procps-ng/procps/issues/4https://github.com/limingth/sysvinit/blob/master/sysvinit-2.88dsf/src/killall5.c#L800
If SELINUX is enabled but the machine is using another MAC system
(like apparmor), ps will fallback to just parsing
"/proc/%d/attr/current", otherwise the label/context would not
be properly displayed in that case.
References:
https://bugs.debian.org/786956
Signed-off-by: Craig Small <csmall@enc.com.au>
The cgroup field while shown as a vector is a concatenated
string, so alot of the complexity of sorting and displaying
has gone.
This change simplifies the cgroup sorting and adds display
and sorting for the name attribute of the cgroup, if found.
Signed-off-by: Craig Small <csmall@enc.com.au>
A rather small fix to sort by cgroup. This sorting function
could be used for other string vector entries, but I can't
see why you want to for, say, environment.
Reference:
https://bugs.debian.org/692279
Signed-off-by: Craig Small <csmall@enc.com.au>
procps v3.3.11 will bring Library API 5:0:0
The reason for the change is the removal of some calls and
the addition of others. The newlib branch should hopefully
reset some of these changes to a much slower pace.
Signed-off-by: Craig Small <csmall@enc.com.au>
If the -s option was the first option on the command line, free
would report seconds argument failed. This only appeared on the
Debian free, not the one in git.
Closer examination revealed that if a valid float string is
given to strtof() it doesn't set errno to 0, but just leaves it
alone. As we are explicitly testing errno for overflows, this
means the previous errno change is picked up here.
The simple answer is to set errno to 0 before calling strtof().
References:
https://bugs.debian/org/733758https://enc.com.au/2015/08/08/be-careful-with-errno/
This patch just eliminates some eol whitespace, adds a
missing eof newline and contributes yet one additional
entry to the NEWS summary regarding saved top rcfiles.
Signed-off-by: Jim Warner <james.warner@comcast.net>
ps has two columns showing the same data which is elapsed time, just
the format is changed:
etimes - elapsed time in seconds
etime - elapsed time in DD-hh:mm:ss
ps used to only sort by etime but not etimes, by making etimes
and alias of etime for sorting both flags work.
References:
https://bugs.debian.org/794619
Signed-off-by: Craig Small <csmall@enc.com.au>
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>
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>
For over a decade top has used a startup configuration
mimicking the original redhat top. This decision dates
back to when the forked Sourceforge version was trying
to win over users in battles with that ancient kludge.
Will anybody deny that those defaults are coyote ugly?
Well, it is time that top presented a more modern look
at startup, providing that no saved rcfile exists. But
just in case some distro prefers that old, comfortable
look, there's the '--disable-modern-top' build option.
[ Pssst. With the widened memory fields it turns out ]
[ the 'Mem' default window had become almost useless ]
[ on an 80x24 terminal since %CPU & COMMAND were out ]
[ of view. So some other defaults were tweaked a bit ]
[ whether or not --disable-modern-top was specified. ]
Reference(s)
http://www.freelists.org/post/procps/tops-graph-mode-saga-continues,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup argument parsing was recently enhanced to
account for LC_NUMERIC settings, some user input logic
dealing with numbers fails to exploit that capability.
This patch extends such enhancements to a running top.
Reference(s):
commit f7b84f45c7http://www.freelists.org/post/procps/topwatch-floating-point-input,2
Signed-off-by: Jim Warner <james.warner@comcast.net>
SIGCONT is a continue signal. It seems that some zsh setups can send
this signal, causing ps to abort. This is not what "continue" means.
This change just uses the default handler which will continue a stopped
process.
References:
http://bugs.debian.org/732410http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=32251
Signed-off-by: Craig Small <csmall@enc.com.au>
If top were invoked under the 'screen' window manager,
writing the terminfo string 'exit_ca_mode' at top exit
would not restore the display to the state existing at
the time top was started. That's what occurs normally.
The net result of that failure was a corrupted screen.
However, there is a 'screen' configuration option that
will produce proper 'rmcup' behavior, but it is off by
default. That screencr option is known as 'altscreen'.
I stumbled across this provision by cloning the screen
git repository then searching for references to 'cup'.
If 'altscreen on' had been in either the /etc/screenrc
or the $HOME/.screenrc configuration file, my poor old
top would never have been accused of such corruptions.
Of course, the Programming Gods decree that any simple
solution for our problem must always be revealed last.
So before discovering that rc option, another approach
was taken involving top only. With just a little extra
refactoring of top display logic he was made immune to
any such quirk in the implementation of 'smcup/rmcup'.
I always feel good about any enhancement that actually
reduces the total number of lines of code. Even though
this change involved mostly rearranging some logic, it
yielded one less line (can't judge by diffstat because
of braces & notes). Anyway, rather than requiring some
change to a screenrc file, now we are self-sufficient.
Reference(s):
procps ---------------------------------------------
https://bugzilla.redhat.com/show_bug.cgi?id=962022http://www.freelists.org/post/procps/top-procpsng337-no-screen-cleaning-at-exit,3
. top : disable tty scrollback buffer to improve SIGWINCH
commit dedaf6e1a8
screen ---------------------------------------------
git://git.sv.gnu.org/screen.git
. Improve cursor store/restore on smcup/rmcup.
commit f95352946080be803b794c9f2733d8c809c1a39a
. Fix using alternate screen buffers in some cases.
commit ad56f746c6243d45124485d198d577bdbb78071c
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558724
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides the NEWS and man document changes
supporting the new NUMA/Node top program enhancements.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
This commit provides the hard copy support for our new
'Other Filter' feature. The man document contains some
potentially useful examples and it will be interesting
to see what use this new tool is put to in the future.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
freeproc was missing from the libproc API which meant while you could
allocate proc structures, you couldn't free them!
Bug-Debian: http://bugs.debian.org/681653
