2017-02-04 06:14:01 +05:30
|
|
|
.\"
|
2023-02-08 12:58:55 +05:30
|
|
|
.\" Copyright (c) 2004-2023 Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
.\" Copyright (c) 2013-2023 Jim Warner <james.warner@comcast.net>
|
|
|
|
|
.\" Copyright (c) 2011-2012 Sami Kerola <kerolasa@iki.fi>
|
|
|
|
|
.\" Copyright (c) 2002-2004 Albert Cahalan
|
|
|
|
|
.\" Copyright (c) 2000 Kjetil Torgrim Homme
|
2017-02-04 06:14:01 +05:30
|
|
|
.\"
|
|
|
|
|
.\" This program is free software; you can redistribute it and/or modify
|
|
|
|
|
.\" it under the terms of the GNU General Public License as published by
|
|
|
|
|
.\" the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
.\" (at your option) any later version.
|
2002-02-02 04:17:29 +05:30
|
|
|
.\"
|
2023-01-16 12:59:50 +05:30
|
|
|
.TH PGREP "1" "2023-01-16" "procps-ng" "User Commands"
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH NAME
|
2021-02-15 15:40:06 +05:30
|
|
|
pgrep, pkill, pidwait \- look up, signal, or wait for processes based on name and other attributes
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH SYNOPSIS
|
2011-09-28 02:12:51 +05:30
|
|
|
.B pgrep
|
|
|
|
|
[options] pattern
|
|
|
|
|
.br
|
|
|
|
|
.B pkill
|
|
|
|
|
[options] pattern
|
2020-02-24 08:32:59 +05:30
|
|
|
.br
|
2021-02-15 15:40:06 +05:30
|
|
|
.B pidwait
|
2020-02-24 08:32:59 +05:30
|
|
|
[options] pattern
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH DESCRIPTION
|
2011-09-28 02:12:51 +05:30
|
|
|
.B pgrep
|
|
|
|
|
looks through the currently running processes and lists the process IDs which
|
2013-02-13 23:06:11 +05:30
|
|
|
match the selection criteria to stdout. All the criteria have to match.
|
2011-09-28 02:12:51 +05:30
|
|
|
For example,
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
|
|
|
|
$ pgrep \-u root sshd
|
|
|
|
|
.PP
|
2011-09-28 02:12:51 +05:30
|
|
|
will only list the processes called
|
|
|
|
|
.B sshd
|
|
|
|
|
AND owned by
|
|
|
|
|
.BR root .
|
2002-02-02 04:17:29 +05:30
|
|
|
On the other hand,
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
|
|
|
|
$ pgrep \-u root,daemon
|
|
|
|
|
.PP
|
2011-09-28 02:12:51 +05:30
|
|
|
will list the processes owned by
|
|
|
|
|
.B root
|
|
|
|
|
OR
|
|
|
|
|
.BR daemon .
|
|
|
|
|
.PP
|
|
|
|
|
.B pkill
|
|
|
|
|
will send the specified signal (by default
|
|
|
|
|
.BR SIGTERM )
|
2002-02-02 04:17:29 +05:30
|
|
|
to each process instead of listing them on stdout.
|
2020-02-24 08:32:59 +05:30
|
|
|
.PP
|
2021-02-15 15:40:06 +05:30
|
|
|
.B pidwait
|
2020-02-24 08:32:59 +05:30
|
|
|
will wait for each process instead of listing them on stdout.
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH OPTIONS
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-\fR\fIsignal\fP
|
|
|
|
|
.TQ
|
|
|
|
|
\fB\-\-signal\fR \fIsignal\fR
|
|
|
|
|
Defines the signal to send to each matched process. Either the numeric or
|
pgrep: Support matching on the presence of a userspace signal handler
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>
2022-11-01 05:47:21 +05:30
|
|
|
the symbolic signal name can be used. In
|
|
|
|
|
.B pgrep
|
|
|
|
|
or
|
|
|
|
|
.B pidwait
|
2023-03-01 12:05:14 +05:30
|
|
|
mode only the long option can be used and has no effect unless used in conjunction with
|
pgrep: Support matching on the presence of a userspace signal handler
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>
2022-11-01 05:47:21 +05:30
|
|
|
\fB\-\-require\-handler\fR to filter to processes with a userspace signal
|
|
|
|
|
handler present for a particular signal.
|
|
|
|
|
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-c\fR, \fB\-\-count\fR
|
2012-01-25 13:47:49 +05:30
|
|
|
Suppress normal output; instead print a count of matching processes. When
|
|
|
|
|
count does not match anything, e.g. returns zero, the command will return
|
2021-02-15 15:40:06 +05:30
|
|
|
non-zero value. Note that for pkill and pidwait, the count is the number of
|
2020-02-24 08:32:59 +05:30
|
|
|
matching processes, not the processes that were successfully signaled or waited
|
|
|
|
|
for.
|
2011-09-28 02:12:51 +05:30
|
|
|
.TP
|
2012-10-11 16:04:50 +05:30
|
|
|
\fB\-d\fR, \fB\-\-delimiter\fR \fIdelimiter\fP
|
2011-09-28 02:12:51 +05:30
|
|
|
Sets the string used to delimit each process ID in the output (by default a
|
|
|
|
|
newline).
|
|
|
|
|
.RB ( pgrep
|
|
|
|
|
only.)
|
|
|
|
|
.TP
|
2020-11-06 20:15:56 +05:30
|
|
|
\fB\-e\fR, \fB\-\-echo\fR
|
|
|
|
|
Display name and PID of the process being killed.
|
|
|
|
|
.RB ( pkill
|
|
|
|
|
only.)
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-f\fR, \fB\-\-full\fR
|
|
|
|
|
The
|
|
|
|
|
.I pattern
|
|
|
|
|
is normally only matched against the process name. When
|
|
|
|
|
.B \-f
|
|
|
|
|
is set, the full command line is used.
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-g\fR, \fB\-\-pgroup\fR \fIpgrp\fP,...
|
|
|
|
|
Only match processes in the process group IDs listed. Process group 0 is
|
|
|
|
|
translated into
|
2020-02-24 08:32:59 +05:30
|
|
|
.BR pgrep 's,
|
|
|
|
|
.BR pkill 's,
|
2011-09-28 02:12:51 +05:30
|
|
|
or
|
2021-02-15 15:40:06 +05:30
|
|
|
.BR pidwait 's
|
2011-09-28 02:12:51 +05:30
|
|
|
own process group.
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-G\fR, \fB\-\-group\fR \fIgid\fP,...
|
|
|
|
|
Only match processes whose real group ID is listed. Either the numerical or
|
|
|
|
|
symbolical value may be used.
|
|
|
|
|
.TP
|
2015-05-10 13:12:09 +05:30
|
|
|
\fB\-i\fR, \fB\-\-ignore\-case\fR
|
|
|
|
|
Match processes case-insensitively.
|
|
|
|
|
.TP
|
2012-05-06 16:34:41 +05:30
|
|
|
\fB\-l\fR, \fB\-\-list\-name\fR
|
2011-09-28 02:12:51 +05:30
|
|
|
List the process name as well as the process ID.
|
|
|
|
|
.RB ( pgrep
|
|
|
|
|
only.)
|
2012-05-06 16:34:41 +05:30
|
|
|
.TP
|
2012-08-18 05:50:27 +05:30
|
|
|
\fB\-a\fR, \fB\-\-list\-full\fR
|
|
|
|
|
List the full command line as well as the process ID.
|
|
|
|
|
.RB ( pgrep
|
|
|
|
|
only.)
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-n\fR, \fB\-\-newest\fR
|
|
|
|
|
Select only the newest (most recently started) of the matching processes.
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-o\fR, \fB\-\-oldest\fR
|
|
|
|
|
Select only the oldest (least recently started) of the matching processes.
|
|
|
|
|
.TP
|
2020-05-17 18:30:27 +05:30
|
|
|
\fB\-O\fR, \fB\-\-older\fR \fIsecs\fP
|
|
|
|
|
Select processes older than secs.
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-P\fR, \fB\-\-parent\fR \fIppid\fP,...
|
2002-02-02 04:17:29 +05:30
|
|
|
Only match processes whose parent process ID is listed.
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-s\fR, \fB\-\-session\fR \fIsid\fP,...
|
2002-02-02 04:17:29 +05:30
|
|
|
Only match processes whose process session ID is listed. Session ID 0
|
2011-09-28 02:12:51 +05:30
|
|
|
is translated into
|
2020-02-24 08:32:59 +05:30
|
|
|
.BR pgrep 's,
|
|
|
|
|
.BR pkill 's,
|
2011-09-28 02:12:51 +05:30
|
|
|
or
|
2021-02-15 15:40:06 +05:30
|
|
|
.BR pidwait 's
|
2011-09-28 02:12:51 +05:30
|
|
|
own session ID.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-t\fR, \fB\-\-terminal\fR \fIterm\fP,...
|
|
|
|
|
Only match processes whose controlling terminal is listed. The terminal name
|
|
|
|
|
should be specified without the "/dev/" prefix.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-u\fR, \fB\-\-euid\fR \fIeuid\fP,...
|
|
|
|
|
Only match processes whose effective user ID is listed. Either the numerical
|
|
|
|
|
or symbolical value may be used.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-U\fR, \fB\-\-uid\fR \fIuid\fP,...
|
|
|
|
|
Only match processes whose real user ID is listed. Either the numerical or
|
|
|
|
|
symbolical value may be used.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-v\fR, \fB\-\-inverse\fR\fR
|
2013-03-11 11:30:00 +05:30
|
|
|
Negates the matching. This option is usually used in
|
|
|
|
|
.BR pgrep 's
|
2020-02-24 08:32:59 +05:30
|
|
|
or
|
2021-02-15 15:40:06 +05:30
|
|
|
.BR pidwait 's
|
2013-02-13 23:06:11 +05:30
|
|
|
context. In
|
|
|
|
|
.BR pkill 's
|
2012-02-14 01:48:54 +05:30
|
|
|
context the short option is disabled to avoid accidental usage of the option.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2013-03-18 16:28:47 +05:30
|
|
|
\fB\-w\fR, \fB\-\-lightweight\fR\fR
|
|
|
|
|
Shows all thread ids instead of pids in
|
|
|
|
|
.BR pgrep 's
|
2020-02-24 08:32:59 +05:30
|
|
|
or
|
2021-02-15 15:40:06 +05:30
|
|
|
.BR pidwait 's
|
2013-03-18 16:28:47 +05:30
|
|
|
context. In
|
|
|
|
|
.BR pkill 's
|
|
|
|
|
context this option is disabled.
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-x\fR, \fB\-\-exact\fR\fR
|
2020-06-04 17:55:26 +05:30
|
|
|
Only match processes whose names (or command lines if \fB\-f\fR is specified)
|
2011-09-28 02:12:51 +05:30
|
|
|
.B exactly
|
|
|
|
|
match the
|
|
|
|
|
.IR pattern .
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-F\fR, \fB\-\-pidfile\fR \fIfile\fR
|
2020-02-24 08:32:59 +05:30
|
|
|
Read \fIPID\fRs from \fIfile\fR. This option is more useful for
|
2023-01-16 12:59:50 +05:30
|
|
|
.B pkill
|
|
|
|
|
or
|
|
|
|
|
.B pidwait
|
2011-09-28 02:12:51 +05:30
|
|
|
than
|
|
|
|
|
.BR pgrep .
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-L\fR, \fB\-\-logpidfile\fR
|
2020-06-04 17:55:26 +05:30
|
|
|
Fail if pidfile (see \fB\-F\fR) not locked.
|
2011-09-28 02:12:51 +05:30
|
|
|
.TP
|
2019-01-04 04:04:14 +05:30
|
|
|
\fB\-r\fR, \fB\-\-runstates\fR \fID,R,S,Z,\fP...
|
|
|
|
|
Match only processes which match the process state.
|
|
|
|
|
.TP
|
2022-08-10 18:37:38 +05:30
|
|
|
\fB\-A\fR, \fB\-\-ignore-ancestors\fR\fR
|
|
|
|
|
Ignore all ancestors of
|
|
|
|
|
.BR pgrep ,
|
|
|
|
|
.BR pkill ,
|
|
|
|
|
or
|
|
|
|
|
.BR pidwait .
|
|
|
|
|
For example, this can be useful when elevating with
|
|
|
|
|
.BR sudo
|
|
|
|
|
or similar tools.
|
|
|
|
|
.TP
|
pgrep: Support matching on the presence of a userspace signal handler
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>
2022-11-01 05:47:21 +05:30
|
|
|
\fB\-H\fR, \fB\-\-require\-handler\fR\fR
|
|
|
|
|
Only match processes with a userspace signal handler present for the signal to
|
|
|
|
|
be sent.
|
|
|
|
|
.TP
|
2021-10-26 15:26:19 +05:30
|
|
|
\fB\-\-cgroup \fIname\fP,...
|
|
|
|
|
Match on provided control group (cgroup) v2 name. See
|
|
|
|
|
.BR cgroups (8)
|
|
|
|
|
.TP
|
2013-04-13 00:10:27 +05:30
|
|
|
\fB\-\-ns \fIpid\fP
|
|
|
|
|
Match processes that belong to the same namespaces. Required to run as
|
2020-06-04 17:55:26 +05:30
|
|
|
root to match processes from other users. See \fB\-\-nslist\fR for how to
|
|
|
|
|
limit which namespaces to match.
|
2013-04-13 00:10:27 +05:30
|
|
|
.TP
|
|
|
|
|
\fB\-\-nslist \fIname\fP,...
|
|
|
|
|
Match only the provided namespaces. Available namespaces:
|
2023-01-16 12:59:50 +05:30
|
|
|
ipc, mnt, net, pid, user, uts.
|
2013-04-13 00:10:27 +05:30
|
|
|
.TP
|
2020-04-25 08:45:06 +05:30
|
|
|
\fB\-q\fR, \fB\-\-queue \fIvalue\fP
|
|
|
|
|
Use
|
2023-01-16 12:59:50 +05:30
|
|
|
.BR sigqueue (3)
|
2020-04-25 08:45:06 +05:30
|
|
|
rather than
|
2023-01-16 12:59:50 +05:30
|
|
|
.BR kill (2)
|
2020-04-25 08:45:06 +05:30
|
|
|
and the value argument is used to specify
|
|
|
|
|
an integer to be sent with the signal. If the receiving process has
|
|
|
|
|
installed a handler for this signal using the SA_SIGINFO flag to
|
2023-01-16 12:59:50 +05:30
|
|
|
.BR sigaction (2),
|
|
|
|
|
then it can obtain this data via the si_value field of the
|
2020-04-25 08:45:06 +05:30
|
|
|
siginfo_t structure.
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
\fB\-V\fR, \fB\-\-version\fR
|
|
|
|
|
Display version information and exit.
|
|
|
|
|
.TP
|
|
|
|
|
\fB\-h\fR, \fB\-\-help\fR
|
|
|
|
|
Display help and exit.
|
|
|
|
|
.PD
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH OPERANDS
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
.I pattern
|
|
|
|
|
Specifies an Extended Regular Expression for matching against the process
|
|
|
|
|
names or command lines.
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH EXAMPLES
|
2011-09-28 02:12:51 +05:30
|
|
|
Example 1: Find the process ID of the
|
|
|
|
|
.B named
|
|
|
|
|
daemon:
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
|
|
|
|
$ pgrep \-u root named
|
|
|
|
|
.PP
|
2011-09-28 02:12:51 +05:30
|
|
|
Example 2: Make
|
|
|
|
|
.B syslog
|
|
|
|
|
reread its configuration file:
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
|
|
|
|
$ pkill \-HUP syslogd
|
|
|
|
|
.PP
|
2011-09-28 02:12:51 +05:30
|
|
|
Example 3: Give detailed information on all
|
|
|
|
|
.B xterm
|
|
|
|
|
processes:
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
|
|
|
|
$ ps \-fp $(pgrep \-d, \-x xterm)
|
|
|
|
|
.PP
|
2011-09-28 02:12:51 +05:30
|
|
|
Example 4: Make all
|
2017-12-22 09:26:08 +05:30
|
|
|
.B chrome
|
2011-09-28 02:12:51 +05:30
|
|
|
processes run nicer:
|
2011-02-23 13:47:54 +05:30
|
|
|
.IP
|
2017-12-22 09:26:08 +05:30
|
|
|
$ renice +4 $(pgrep chrome)
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH "EXIT STATUS"
|
2011-02-23 13:47:54 +05:30
|
|
|
.PD 0
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
0
|
2023-01-16 12:59:50 +05:30
|
|
|
One or more processes matched the criteria. For
|
|
|
|
|
.B pkill
|
|
|
|
|
and
|
|
|
|
|
.BR pidwait ,
|
|
|
|
|
one or more
|
2020-02-24 08:32:59 +05:30
|
|
|
processes must also have been successfully signalled or waited for.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
1
|
2017-02-04 06:14:01 +05:30
|
|
|
No processes matched or none of them could be signalled.
|
2002-02-02 04:17:29 +05:30
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
2
|
2002-02-02 04:17:29 +05:30
|
|
|
Syntax error in the command line.
|
|
|
|
|
.TP
|
2011-09-28 02:12:51 +05:30
|
|
|
3
|
2002-02-02 04:17:29 +05:30
|
|
|
Fatal error: out of memory etc.
|
2011-09-28 02:12:51 +05:30
|
|
|
.PD
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH NOTES
|
2011-09-28 02:12:51 +05:30
|
|
|
The process name used for matching is limited to the 15 characters present in
|
2020-06-04 17:55:26 +05:30
|
|
|
the output of /proc/\fIpid\fP/stat. Use the \fB\-f\fR option to match against the
|
2015-12-01 10:30:00 +05:30
|
|
|
complete command line, /proc/\fIpid\fP/cmdline. Threads may not have the
|
2015-09-26 03:49:32 +05:30
|
|
|
same process name as the parent process but will have the same command line.
|
2011-09-28 02:12:51 +05:30
|
|
|
.PP
|
|
|
|
|
The running
|
2020-02-24 08:32:59 +05:30
|
|
|
.BR pgrep ,
|
|
|
|
|
.BR pkill ,
|
2011-09-28 02:12:51 +05:30
|
|
|
or
|
2021-02-15 15:40:06 +05:30
|
|
|
.B pidwait
|
2011-09-28 02:12:51 +05:30
|
|
|
process will never report itself as a
|
|
|
|
|
match.
|
2021-12-16 15:06:00 +05:30
|
|
|
.PP
|
|
|
|
|
The
|
|
|
|
|
.B \-O \-\-older
|
2023-01-16 12:59:50 +05:30
|
|
|
option will silently fail if \fI/proc\fR is mounted with the \fIsubset=pid\fR option.
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH BUGS
|
2011-09-28 02:12:51 +05:30
|
|
|
The options
|
|
|
|
|
.B \-n
|
|
|
|
|
and
|
|
|
|
|
.B \-o
|
|
|
|
|
and
|
|
|
|
|
.B \-v
|
|
|
|
|
can not be combined. Let
|
|
|
|
|
me know if you need to do this.
|
|
|
|
|
.PP
|
2002-02-02 04:17:29 +05:30
|
|
|
Defunct processes are reported.
|
2022-07-18 16:21:41 +05:30
|
|
|
.PP
|
|
|
|
|
.B pidwait
|
|
|
|
|
requires the
|
|
|
|
|
.BR pidfd_open (2)
|
|
|
|
|
system call which first appeared in Linux 5.3.
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH "SEE ALSO"
|
2011-02-23 13:47:54 +05:30
|
|
|
.BR ps (1),
|
|
|
|
|
.BR regex (7),
|
|
|
|
|
.BR signal (7),
|
2020-04-25 08:45:06 +05:30
|
|
|
.BR sigqueue (3),
|
2011-02-23 13:47:54 +05:30
|
|
|
.BR killall (1),
|
|
|
|
|
.BR skill (1),
|
|
|
|
|
.BR kill (1),
|
2021-10-26 15:26:19 +05:30
|
|
|
.BR kill (2),
|
2023-01-16 12:59:50 +05:30
|
|
|
.BR cgroups (8).
|
2002-02-02 04:17:29 +05:30
|
|
|
.SH AUTHOR
|
2012-04-16 16:25:53 +05:30
|
|
|
.UR kjetilho@ifi.uio.no
|
2011-09-28 02:12:51 +05:30
|
|
|
Kjetil Torgrim Homme
|
|
|
|
|
.UE
|
|
|
|
|
.SH "REPORTING BUGS"
|
|
|
|
|
Please send bug reports to
|
2012-04-16 16:25:53 +05:30
|
|
|
.UR procps@freelists.org
|
2011-09-28 02:12:51 +05:30
|
|
|
.UE
|
