In some cases the --terminal option to pgrep will cause all processes
matching the terminal to be output, even if other criteria would exclude them.
Specifically, I noticed that it overrides the --runstates option.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
With the commit shown below a BOT_PRESENT constant was
introduced. Unfortunately it was defined in a way that
disable ^L (message log) and ^P (namespaces) highlight
when using the tab key. This patch fixes such an oops.
Reference(s):
. Jan, 2023 - lessen 'bottom window' overhead
commit 28f44729da
Signed-off-by: Jim Warner <james.warner@comcast.net>
The lstart field has been converted to use the strftime()
function so that it uses the locale. A new option -D
allows the user to define the format that would want this
field to show.
This may mean the field will be longer than it should be,
especially for French locales and the user defined field,
but the field length can be specified too.
---
This commit started off making all the relevant fields use the
locale correctly so it could solve #226 as well. The issue
is there an implied restriction (or not) around
strftime("%b") and probably strftime("%a") for abbrievated month
and day names respectively.
English, and some/most other languages put an additional
restriction that all abbreviations are 3 characters long.
The problem is, not all languages do this.
French is a good example:
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Maybe strip the . at the end?
That helps for some months, not all
Maybe take the first three characters?
Several wide languages will have big issues
Maybe convert wide, get wcslen then use that.
Even after that June "juin" and July "juil" are both "jui".
So, anything that uses the month (bsdstart,start) use ctime which
doesn't use locale. That solves the length issue.
stime does, which means it has this issue but its been like that
for years. You get stuff like this:
janv.13 482261
00:00 1151918
2022 1458628
06:12 1957584
The only way to fix that would be to
a)Make the field two characters longer
b)Convert it back to ctime() which means everyone else
loses.
This could have be oh-so easy if everyone made %b and %a three
(wide) characters everywhere.
References:
procps-ng/procps#228procps-ng/procps#226
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Fix conversion errors due to precision issues in function unitConvert
For example: unitConvert(98720620) will return 98720624, not 98720620.
Because we do (unsigned long)(float)98720620 in function unitConvert
and this is wrong! We should do (unsigned long)(double)98720620 here.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!75
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.
Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.
After some fiddling around, the exact problematic behavior appears to be
as follows:
1. Lines which would have wrapped (more than $COLUMNS chars long) are
handled correctly.
2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
printed; but then the next line is *not* printed! For long sequences
of non-wrap-length lines, you get an every-other-line-is-visible
sort of effect.
The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.
However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.
Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.
References:
procps-ng/procps!157
Signed-off-by: Craig Small <csmall@dropbear.xyz>
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.
References:
procps-ng/procps!125procps-ng/procps#190
Updated the definition of total, because its not *all* of
the installed memory but close to it.
References:
procps-ng/procps#247
Signed-off-by: Craig Small <csmall@dropbear.xyz>
In production we've had several incidents over the years where a process
has a signal handler registered for SIGHUP or one of the SIGUSR signals
which can be used to signal a request to reload configs, rotate log
files, and the like. While this may seem harmless enough, what we've
seen happen repeatedly is something like the following:
1. A process is using SIGHUP/SIGUSR[12] to request some
application-handled state change -- reloading configs, rotating a log
file, etc;
2. This kind of request is deprecated and removed, so the signal handler
is removed. However, a site where the signal might be sent from is
missed (often logrotate or a service manager);
3. Because the default disposition of these signals is terminal, sooner
or later these applications are going to be sent SIGHUP or similar
and end up unexpectedly killed.
I know for a fact that we're not the only organisation experiencing
this: in general, signal use is pretty tricky to reason about and safely
remove because of the fairly aggressive SIG_DFL behaviour for some
common signals, especially for SIGHUP which has a particularly ambiguous
meaning. Especially in a large, highly interconnected codebase,
reasoning about signal interactions between system configuration and
applications can be highly complex, and it's inevitable that on occasion
a callsite will be missed.
In some cases the right call to avoid this will be to migrate services
towards other forms of IPC for this purpose, but inevitably there will
be some services which must continue using signals, so we need a safe
way to support them.
This patch adds support for the -H/--require-handler flag, which matches
on processes with a userspace handler present for the signal being sent.
With this flag we can enforce that all SIGHUP reload cases and SIGUSR
equivalents use --require-handler. This effectively mitigates the case
we've seen time and time again where SIGHUP is used to rotate log files
or reload configs, but the sending site is mistakenly left present after
the removal of signal handler, resulting in unintended termination of
the process.
Signed-off-by: Chris Down <chris@chrisdown.name>
When the p/e-cores support (via the '5' key) was added
in the patch referenced below, I intentionally omitted
that key from the top primary help screen. This seemed
appropriate since it only applied to select Intel cpus
and, besides, that screen was getting kind of crowded.
[ it remains an objective to fit on a 80x24 terminal ]
Upon reflection, I found a way to squeeze it into that
help screen and have decided to included it. Hopefully
its presence will encourage use of top's new provision
on any Intel platforms that distinguish between cores.
Reference(s):
Sep, 2022 - exploit p/e-cores provision
commit 00f5c74b1b
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the commits referenced below special code was added
to make the bottom window sticky and fix the bug after
'Cap_nl_clreos' was traded for the 'Cap_clr_eol' loop.
However, there's always major overhead associated with
interacting with a terminal. So we'll only abandon the
single 'Cap_nl_clreos' putp in favor of repeated calls
with 'Cap_clr_eol' when a bottom window isn't present.
Reference(s):
. May, 2022 - bottom window batch bug fix
commit 793f3e85ae
. May, 2022 - bottom window made sticky
commit 0f2a755b0b
Signed-off-by: Jim Warner <james.warner@comcast.net>
Please, do not look at the actual changes made by this
commit. Trust me they will vastly improve performance.
Signed-off-by: Jim Warner <james.warner@comcast.net>
vmstat <n> would update most fields, but the memory statistics
were only fetched the first time.
References:
https://bugs.debian.org/1027963
Signed-off-by: Craig Small <csmall@dropbear.xyz>
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>
The man page said it cannot show changes to comm, such as when you
use prctl(). In fact, ps can see this. The args field may not change
because its due to the path of the executable but comm can.
The field comm no longer shows defunct for zombie processes, use the
state field for this as it could be obscured if not the last
column anyhow.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
When the skill program was ported to the new API the code to filter
on PID, used by the -p option, was missed. It is now restored.
References:
https://bugs.debian.org/1025915
While ps used the correct type for PIDS_VM_RSS the test
did not. For some reason this only appeared to be an issue
for s390x
References:
https://bugs.debian.org/1025495
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Put the man-po pot file under version control like its po/*.pot sibling.
Makefile now auto-matically generates the list of man pages as they are
in a single directory. There were some missing!
pot file target is dependent on the untranslated man pages
When downloading from translation project, run po4a to sync the new
po files correctly.
Downloaded man po files from translation project and synched.
Thanks to @gorean for the info
References:
procps-ng/procps#258
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Commit c8384e682c ("pgrep: add pwait") changed from the old i_am_pkill
logic, but mistakenly missed a break in the pkill case. This results in
showing -e/--echo twice when running `pkill -h'.
Signed-off-by: Chris Down <chris@chrisdown.name>
Replace AC_CHECK_FUNC by AC_CHECK_FUNCS otherwise HAVE_PIDFD_OPEN will
never be defined resulting in the following build failure if pidfd_open
is available but __NR_pidfd_open is not available:
pgrep.c: In function 'pidfd_open':
pgrep.c:748:17: error: '__NR_pidfd_open' undeclared (first use in this function); did you mean 'pidfd_open'?
748 | return syscall(__NR_pidfd_open, pid, flags);
| ^~~~~~~~~~~~~~~
| pidfd_open
This build failure is raised since the addition of pwait in version
3.3.17 and
c8384e682c
Fixes:
- http://autobuild.buildroot.org/results/f23a5156e641b2ebdd673973dec0f9c87760c688
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Thanks to @kabe-gl for this patch.
w command shows ????? for LOGIN@ column when compiled on 32bit environment with -D_TIME_BITS=64.
References:
#256
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Just as our library was made responsive to a potential
missing 'core id', the top program should also change.
That's because he has his own PRETENDECORE #define and
if that was activated on a platform without 'core id',
the 'CpP' notations would have otherwise been omitted.
Reference(s):
. Oct, 2022 - library fix for missing 'core id'
commit b89e3230b2
Signed-off-by: Jim Warner <james.warner@comcast.net>
Tracking what we do to the library so the N:N:N version strings are
updated. This is just a NEWS item for previous commit.
References:
commit b89e3230b2
