Configure maximum number of process identifiers
Sets kernel.pid_max = 65536 so the system has a sufficiently large PID space and is less likely to exhaust process identifiers.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
kernel.pid_max sets the upper limit on process identifiers (PIDs). If this ceiling is too low, the system can exhaust all available PIDs and become unable to fork new processes, which is both an availability hazard and a target for a fork-bomb style denial of service. Raising it to at least 65536 enlarges the PID space and improves availability under load.
What Pavois checks
Pavois reads the live kernel value with kernel_parameter('kernel.pid_max') (equivalent to sysctl kernel.pid_max), not a /etc/sysctl.d/*.conf line. A config file is meaningless if it was never applied or a later drop-in overrode it; only the effective parameter reflects the PID ceiling the kernel currently enforces.
describe kernel_parameter('kernel.pid_max') do
its('value') { should cmp >= 65536 }
endHow to verify it is applied
Run sysctl kernel.pid_max. Expected output (value of at least 65536):
kernel.pid_max = 65536
Inspect & investigate
No dedicated log line. Confirm with sysctl kernel.pid_max. PID-exhaustion symptoms appear in dmesg/journalctl -k and application logs as fork: Resource temporarily unavailable / Cannot allocate memory when no PID is free.
Remediation
Pavois's harden plan uses the sysctl resource to set kernel.pid_max = 65536, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.pid_max |
|---|---|
| resource | sysctl |
| value | 4194304 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: a low PID ceiling can be reached under heavy process load (or a fork bomb), after which the system cannot start new processes, including login shells and recovery tools.
Precautions before applying:
65536is a baseline. Hosts running thousands of concurrent processes/threads (large container nodes, build farms) may need a higher value (e.g.4194304). Setting it lower than the current running value could constrain a busy system, so confirm the existing value first.- The change is safe and reversible at runtime, with no application or boot lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.