PID file incorrect format

[evandhoffman]

PID file says "pid 6004" instead of just the bare integer.

[evandhoffman]

Detail — and evidence that this may not be monitord's bug

The exact bytes

$ wc -c < monitord.pid
9
$ od -c monitord.pid
0000000    p   i   d       6   0   0   4  \n
0000011

So the content is literally pid 6004\n. The standard idiom fails:

$ kill "$(cat monitord.pid)"
kill: illegal pid: pid 6004

That is how this was found — I was stopping a 13-hour capture and had to fall
back to pgrep -f.

But monitord does not appear to write a pid file at all

Before adding detail I tried to reproduce it, and could not:

$ monitord --dir /tmp/pidtest --interval 1 &
$ ls /tmp/pidtest/
sensors.macbook-pro_local.2026_09_05_22_12_55.csv

No monitord.pid, and no monitord.stderr. Only the CSV.

Searching the source agrees. On origin/main (a500b78, v1.6.2), the only
match for pid anywhere in the repo outside Scripts/make-icon.swift is a
roadmap note about proc_pid_rusage. There is no pid-file writing code, and
monitord --help has no pid, daemon or background flag.

What I think actually happened

The directory that produced this file is
~/.local-llm-bench/sensors/149-route-ab/, which belongs to the local-llm
benchmark harness, not to monitor. It contains:

monitord.pid       9 bytes   Sep  5 08:51
monitord.stderr    0 bytes   Sep  5 08:51
sensors.macbook-pro_local.2026_09_05_08_51_36.csv

A zero-byte .stderr sitting beside a .pid, both created at the same second
as the CSV, is the signature of a wrapper script that redirected stderr and
recorded the process id — almost certainly something like
echo "pid $!" > monitord.pid. That would explain the format exactly: the
word pid is a label someone wrote, not a serialization monitord chose.

I have not yet located that launcher — it is not in the local-llm tree under
any obvious name, and it may have been an ad-hoc command from an earlier
session rather than a committed script.

Suggested disposition

Probably close this and re-file against local-llm, unless monitord writes a
pid file on some path I did not exercise — the daemon/launchd path is the
obvious candidate, and I deliberately did not test the default --dir because
its retention deletes files in ~/Library/Logs/monitor and I did not want to
touch real logs to chase this.

Two things are worth keeping regardless of where it lands:

1. A pid file should contain a bare integer and nothing else. Whoever owns
   this one, kill "$(cat file.pid)" is the contract, and pid 6004 breaks it.
2. If monitord ever does grow a pid file, it should be written atomically and
   removed on exit — this one is still on disk after the process is gone, so a
   reader cannot distinguish "running" from "crashed".

Correcting my own report: I told Evan this file was removed on shutdown. It was
not. My check used cat -A, which macOS cat does not support; I read the
usage error as empty output.