This patch is intended to bring the master branch into
closer alignment with the newlib branch functionality.
The commit shown below replaced that 'escape_str' with
'escaped_copy' so that the ps program wouldn't execute
some code twice. However, it created a problem for the
top program when the UTF-8 encoding was not available.
Unlike ps who calls the escape functions directly, top
outputs those library provided strings unaltered. That
means there is no workaround (like LANG=) when such an
encoding was unavailable. This, in turn, can lead to a
corrupted display (especially with the linux console).
Now, when a UTF-8 encoding is not available, multibyte
chars are converted to '?', reducing display problems.
[ there's still a potential problem concerning 'cmd' ]
[ should program names contain multibyte characters. ]
[ unlike that newlib branch, this string is not ever ]
[ altered with the '?' char under the master branch. ]
Reference(s);
. Dec 2020, escaoed_copy repleced most escape_str
commit eea5626bb1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the ps program is using 'escape_str' for most
of the library's returned strings, this patch tries to
lessen the prospects of executing that function twice.
Our newlib branch has achieved such a goal through the
elimination of nearly all escape.c code. However, here
we avoid API change by trading some 'escape_str' calls
(with wide character overhead) for a slightly extended
'escaped_copy' call (which incurs no multibyte costs).
Note: until we migrate to the newlib version, there is
a remaining call to 'escape_str' which we can't avoid.
Such code involves the 'escape_command' function call.
[ As we prepare for this new (final?) release, there ]
[ were already internal library changes that require ]
[ a new 'revision'. This patch won't impact the API! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When any process' command line contains multibyte utf8
characters, two separate display problems could arise.
1. If that COMMAND column is not displayed as the very
last field, then field(s) to the right are misaligned.
2. Even when last, should utf8 string length (not that
display length) exceed allowable screen width, it will
nonetheless suffer from improper premature truncation.
Number 1 is less of a concern since the cmdline column
is likely to always be the last field to be displayed,
if only to enable right and left scrolling provisions.
Number 2 is much more likely to occur, especially with
additional fields which might be shown before COMMAND.
Or, forest view child tasks can yield the same effect.
So, this commit will permit the correct utf8 multibyte
display regardless of field position or string length.
And, we'll bring top into line with the ps program for
additional fields potentially subject to utf8 display.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Form its inception (back in May of 2011), escaped_copy
has always been a flawed function. It does not operate
on 'escaped' strings but instead treats all input as a
regular string incapable of containing utf8 sequences.
As such, it should only be used for strings guaranteed
to NOT contain multibyte characters (like supgid). For
all other strings, which could contain utf8 stuff, the
correct function should have been that escape_str guy.
So this commit changes nearly every escaped_copy call.
[ note: unlike the newlib guy, the master ps program ]
[ cannot properly handle utf8 multibyte sequences in ]
[ in the recently introduced 'exe' field shown below ]
Reference(s):
. Jun 2018, introduced 'exe' field
commit b556bf5ba8
. May 2011, original escaped_copy (cmdline, cgroup)
commit 7b0fc19e9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
Use NULL in format_array to indicate that the print function shall be
used also for sorting. Change sr_nop() to NULL for all fields which
don't use pr_nop() for printing.
Before the commit (note that '--sort label' has no effect: the rows
are not sorted according to label field):
$ ps -A -o command,label --sort label | grep /lib/systemd
/lib/systemd/systemd-journa system_u:system_r:syslogd_t:s0
/lib/systemd/systemd-udevd system_u:system_r:udev_t:s0-s0:c0.c1023
/lib/systemd/systemd-networ system_u:system_r:systemd_networkd_t:s0
/lib/systemd/systemd-resolv system_u:system_r:systemd_resolved_t:s0
/lib/systemd/systemd-timesy system_u:system_r:ntpd_t:s0
/lib/systemd/systemd-logind system_u:system_r:systemd_logind_t:s0
/lib/systemd/systemd --user user_u:user_r:user_t:s0
/lib/systemd/systemd --user root:sysadm_r:sysadm_t:s0-s0:c0.c1023
grep /lib/systemd user_u:user_r:user_t:s0
After the commit, '--sort label' works and the output is sorted:
$ ps -A -o command,label --sort label | grep /lib/systemd
/lib/systemd/systemd --user root:sysadm_r:sysadm_t:s0-s0:c0.c1023
/lib/systemd/systemd-timesy system_u:system_r:ntpd_t:s0
/lib/systemd/systemd-journa system_u:system_r:syslogd_t:s0
/lib/systemd/systemd-logind system_u:system_r:systemd_logind_t:s0
/lib/systemd/systemd-networ system_u:system_r:systemd_networkd_t:s0
/lib/systemd/systemd-resolv system_u:system_r:systemd_resolved_t:s0
/lib/systemd/systemd-udevd system_u:system_r:udev_t:s0-s0:c0.c1023
/lib/systemd/systemd --user user_u:user_r:user_t:s0
grep /lib/systemd user_u:user_r:user_t:s0
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
This is part of !118 where @tt.rantala found a memory leak.
The other part of !118 may come later if the performance change
is significant.
References:
procps-ng/procps!118
<utmp.h> has been deprecated since 2001 in favour of <utmpx.h>.
On glibc systems, utmp is just an alias to utmpx, so there is no
functional change using one over the other.
However, on the musl libc, a library (utmps) can be used to provide
utmpx functionality - but not utmp. This means that procps either
doesn't work properly (`w` shows nothing under musl with default no-op
implementation), or fails to build (utmps provides utmpx.h but no
utmp.h).
This commit will use utmpx.h where available, which allows `w` to work
correctly with utmps and has no change on glibc systems.
Often pidof is used in shell scripts in this form:
if pidof daemon >/dev/null; then
...
fi
The redirection to /dev/null is needed because otherwise the script
would output the found PIDs.
Let's add a -q option which, similary to grep, just sets the exit code.
Also exit on first match, as there is no reason to proceed further when
at least a process is matched.
Tested with:
$ ./pidof bash
17701 14019 5276 2967
$ echo $?
0
$ ./pidof bashx
$ echo $?
1
$ ./pidof -q bash
$ echo $?
0
$ ./pidof -q bashx
$ echo $?
1
See https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
Support standard and high intensity colors. The default
ncurses colors ARE the high intensity colors - represented
via an 8 bit ansi escape sequence here.
See https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
Support standard and high intensity colors. The default
ncurses colors ARE the high intensity colors - represented
via an 8 bit ansi escape sequence here.
We read /proc/stat using a statically sized buffer. This was increased
to 64kB in 2005 via commit 777fcd3cf1 "/proc/stat for 1024 CPUs".
Unfortunately in 2020, 1024 CPUs is not enough for anyone. I have a
large machine where /proc/stat is 74kB, and vmstat gives incorrect
output.
Double the buffer to 128kB in the confidence that 2048 CPUs is actually
enough for anyone.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
New command, pwait! Waits for another process to finish just like
pgrep finds or pkill kills another process.
References:
procps-ng/procps!97
Signed-off-by: Craig Small <csmall@dropbear.xyz>
With glibc, each time the strftime() function is used (twice per process
in a typical ps -fe run), a stat("/etc/localtime") system call is used
to determine the timezone. Not only does this add extra system call
overhead, but when multiple ps processes are trying to access this
file (or multiple glibc programs using strftime) in parallel, this can
trigger significant lock contention within the OS kernel.
Since ps is not intended to run for long periods of time as a
daemon (during which the system timezone could be altered and PS might
reasonably be expected to adapt its output), there is no benefit to
repeatedly doing this stat(). To stop this behavior, explicitly set the
TZ variable to its default value (:/etc/localtime) whenever it is unset.
glibc will then cache the stat() result.
While sysctl did change the order of /run and /etc to match
systemd in the referenced commit, the Debian bug report that
brought it to light was not documented.
References:
commit 24a1574f0ahttps://bugs.debian.org/950788
If a hash results report was output (via ATEOJ_RPTHSH)
a portion is devoted to occupied table entries ordered
by depth. There is a possibility that some depths will
not be found among existing occupied table entries and
to avoid any confusion probably should not be printed.
[ to illustrate the potential for confusion prior to ]
[ this patch, force a very small table size (like 8) ]
[ and then arrange to trigger the end-of-job report. ]
So this patch ensures only 'in use' entries are shown.
[ admittedly, all of the remaining logic in the loop ]
[ could/should be subordinate to this new 'if' test, ]
[ but we will keep the change to a minimum. besides, ]
[ there's no harm subtracting/adding a zero numdepth ]
[ especially since the chance of a zero is very low. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
free, slabtop and uptime would happily take extra command line
arguments and doing nothing about them. The programs now check
optind after option processing and will give you usage screen
if there is anything extra.
References:
procps-ng/procps#181
For long lines from a process, watch would wrap them around to the
next. While this default option has it uses, sometimes you want to
just cut those long lines down.
watch has a -w flag which will truncate the lines to the number
of columns. A few simple lines to do this new trick.
I think I caught all the ANSI state correctly but there might be
a chance it bleeds to the next row.
References:
procps-ng/procps#182
This patch just raises the size of the hash table used
to calculate elapsed task stuff. The net result should
be less need for 'chaining' under pid hash collisions.
[ the hash scheme is intentionally kept as primitive ]
[ and, therefore, as fast as possible. it employs an ]
[ 'and' approach versus a 'mod' operation since both ]
[ yield similar distribution but the former approach ]
[ was 4 fewer cpu instructions in terms of overhead. ]
[ additionally, for hash collisions, 'chaining' uses ]
[ an array index rather than the usual pointer since ]
[ the HST_t guys may move when they are reallocated. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The referenced commit the comm length was increased from 16 to 64
characters to handle the larger command names for things like kernel
threads.
However most user processes are limited to 15 characters which means
if you try something like ps -C myprogramisbiggerthansixteen this would
fail to match because /proc/<PID>/comm would only be myprogramisbigg
ps now checks the comm length and if it is 15 and if the given match
is 15 or more, it will only match the first 15 characters.
This is also how killall has worked for about a year.
Thanks to Jean Delvare <jdelvare@suse.de> for the note.
References:
commit 14005a371e
commit psmisc/psmisc@1188315cd0
Signed-off-by: Craig Small <csmall@dropbear.xyz>
