This commit is contained in:
connor committed 2026-10-22 09:21:28 -04:00
1 parent 95dc6e146c
commit 226ac906a2
41 files changed
+992 -38

No files matched your search

@@ -0,0 +1,35 @@
---
name: pattern-kill-matches-wrong-process
description: pkill/pgrep/kill %n by pattern repeatedly hit the wrong process or missed the right one; capture PIDs instead
metadata:
type: feedback
---
**Do not manage processes by pattern.** Capture the PID when starting
something and act on that PID. `pgrep -f`, `pkill -f` and `kill %n` have gone
wrong repeatedly across sessions, in every direction:
- `pgrep -f "podman image prune"` matched the monitor's own command line, so
it waited forever on itself. Connor: "I really don't understand why it's
taking this long."
- `pgrep -f "llmbench.cli run"` matched his `tmux new -As llmbench` session
and reported a runner that had finished hours earlier. Eight hours of idle
GPU followed, because the benchmark was reported as running when it was not.
- `hf download ... | head -5 & ... kill %1` killed the shell job but not the
`hf` child, which kept pulling the WHOLE repo -- 69 GB into
`~/.cache/huggingface` before it was spotted in a process listing.
- `pkill -f "llama-server.*9199"` killed the shell that was running the
heredoc writing the next script, so the script silently never existed.
**Why:** a pattern matches the literal command line of EVERY process,
including the shell running the command that contains the pattern, monitors
built from it, tmux sessions named after the project, and editors with the
path open. It also does not follow pipelines or reach children a job-control
kill does not own.
**How to apply:** save `$!` (or the pid from `ps`) and kill that. Where a
pattern is unavoidable, exclude self (`grep -v $$`), print what matched before
killing it, and VERIFY afterwards with `ps -p <pid>` rather than assuming the
kill worked -- several of these failures were "I killed it" followed by the
process still running. To check whether work finished, prefer the durable
record (a run's `ended_at` in the database) over process presence.