dotfiles/common/claude/memory/-home-connor/pattern-kill-matches-wrong-process.md

name, description, metadata

name	description	metadata
pattern-kill-matches-wrong-process	pkill/pgrep/kill %n by pattern repeatedly hit the wrong process or missed the right one; capture PIDs instead	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.