| Previous | Next |
| ENOENT | EINTR |
ESRCH
Process identity is time-sensitive
ESRCH is most familiar from kill(): the supplied process ID or process-group ID did not identify a target at the time the kernel handled the request. The same condition can occur after a child has already been reaped, or when Linux pidfd_open() is asked to obtain a descriptor for a process that has already disappeared.
This is different from EPERM. EPERM means a target was found but the caller was not allowed to signal it; ESRCH means the lookup found no target. A preliminary kill(pid, 0) check can test a PID without sending a signal, but it cannot make a later operation race-free because the process may exit after the check.
What to record and how to handle it
- Log the exact operation, PID or process-group ID, requested signal, and the relevant PID-namespace or service-manager context.
- For a managed child, inspect
waitpid()andSIGCHLDhandling: an earlier wait in another code path may already have consumed the child state. - Decide explicitly whether a missing target means an expected “already stopped” outcome or a control-plane error. Retrying an unchanged raw PID does not recreate the original process.
- On Linux, use a PID file descriptor for long-lived process management when available.
pidfd_send_signal()addresses a stable process reference and reportsESRCHafter that referenced process has terminated, avoiding accidental signaling after PID reuse.
References
Looking for a different code? Search another status or error code.