Summary

The session write lock uses isPidAlive() to determine if a lock holder is still running. In containers (Docker/Kubernetes), PID recycling can cause a different process to inherit the same PID number, making a stale lock appear valid. This leads to session file locked (timeout 10000ms) errors that persist until the 30-minute age-based stale threshold is reached.

This PR adds process start time (/proc/pid/stat field 22) comparison to detect PID recycling:

• Record starttime (clock ticks since boot) in the lock file alongside pid and createdAt
• During staleness checks, compare the stored starttime with the current starttime of that PID
• If the PID is alive but its starttime differs from the recorded value, the lock is treated as stale (recycled-pid) and reclaimed immediately

Why this happens in containers

• Container PID namespaces are small, so PIDs are recycled quickly
• Process respawning (spawn(detached: true)) frees the parent PID for reuse
• Background shell jobs ((…) & in entrypoint scripts) can inherit recycled PIDs
• kill(pid, 0) returns true for the new (unrelated) process, and the lock appears valid

Design

• Industry standard approach: (pid, starttime) comparison is the technique used by psutil, and recommended by kernel developers for /proc/pid/stat-based process identity verification
• lastIndexOf(")") parsing: The only correct way to parse /proc/pid/stat — the comm field can contain spaces and nested parentheses (CVE-2017-1000367, CVE-2021-25683)
• Backward compatible: Lock files without starttime (from older versions) are handled with the existing PID-alive + age-based logic — no false reclamation
• Non-Linux safe: getProcessStartTime() returns null on non-Linux platforms; the field is omitted from lock files and the recycling check is skipped entirely

Changes

Test plan

• All 24 existing + new tests pass (vitest run)
• Recycled PID: lock with alive PID but mismatched starttime is reclaimed immediately
• Backward compat: lock without starttime field is NOT treated as recycled
• Non-Linux: getProcessStartTime returns null, no behavioral change
• Comm field with spaces and nested parentheses: correctly parsed

Greptile Summary

This PR adds PID recycling detection to the session write lock mechanism by recording and comparing process start times. The implementation follows the industry-standard (pid, starttime) approach used by psutil and recommended by kernel developers.

Key changes:

• Added getProcessStartTime() function that reads /proc/pid/stat field 22 (starttime in clock ticks since boot)
• Lock files now store starttime alongside pid and createdAt
• During staleness checks, compares stored starttime with current process starttime to detect PID recycling
• Recycled PIDs are reclaimed immediately (no 30-minute wait) with recycled-pid stale reason
• Backward compatible: old lock files without starttime use existing PID-alive + age-based logic
• Non-Linux safe: getProcessStartTime() returns null on non-Linux platforms, skipping recycling check

Security considerations:

• Uses lastIndexOf(")") parsing to handle comm fields with spaces and nested parentheses, avoiding CVE-2017-1000367 and CVE-2021-25683 vulnerabilities
• Field indexing is correct: field 22 = index 19 after comm-split (field 3 is index 0)

Test coverage:

• Tests verify recycled PID detection and backward compatibility
• Comm field parsing tests cover spaces and nested parentheses
• Comprehensive coverage for Linux, non-Linux, and edge cases

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation is thorough, well-tested, and follows industry best practices. The backward compatibility handling ensures no regressions for existing deployments. The parsing logic correctly handles edge cases documented in security advisories. Tests cover all code paths including PID recycling detection, backward compatibility, non-Linux platforms, and comm field edge cases.
• No files require special attention

_{Last reviewed commit: 49a6bf1}