Updates
This commit is contained in:
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.
|
||||
Reference in new issue
Block a user