After a mise upgrade, doctor reports the history watcher as not running even though the service is up; bootstrap services apply is a no-op

[shawnyeager]

mise doctor reports dotfiles: the history watcher is declared but not running and tells you to run mise bootstrap services apply. On Linux that is a false positive after a package upgrade: the systemd user unit is already running, bootstrap already considers it unchanged, and doctor is looking at a different lock than the live process holds.

This is the leftover from #13038 (“Existing watchers must be stopped and restarted with the updated binary”). Nothing actually restarts the watcher, and doctor’s suggested command does not either.

Environment

• mise 2026.9.5 linux-x64, Arch package at /usr/bin/mise
• systemd user unit dev.mise.mise-history.service (ExecStart=/usr/bin/mise bootstrap dotfiles watch)
• [bootstrap.services.mise-history] builtin = "history-watch"
• [settings.history] sync = "sync" with a connected origin

What I saw

mise doctor:

dotfiles:
  16 tracked entries, watcher declared but not running

1. dotfiles: the history watcher is declared but not running.
        Edits are not saved automatically until it runs; explicit saves still work.
        Run: mise bootstrap services apply

mise doctor --json agreed: "watcher": "declared but not running".

At the same time:

$ systemctl --user is-active dev.mise.mise-history.service
active

$ mise bootstrap services status
unchanged  user-service:mise-history  running  running

$ mise bootstrap status
user-service  mise-history  running  unchanged

health.json was still being written (doctor even reported health_age_secs: 79), and the unit logs showed watches, checkpoints, and origin sync. Edits were being saved. mise bootstrap services apply did nothing, as expected for an unchanged running unit.

Cause

Doctor does not ask systemd. It probes the watch lock via capture_health::watcher() → history::watch::runtime::is_running(state_dir), which looks at $MISE_STATE_DIR/history/watch.lock.

The live watcher had been started before the 2026.9.5 upgrade:

Event	Time
watcher started (MainPID 1577)	11:23:52
pacman installed mise 2026.9.5	11:34:58

So:

$ readlink /proc/1577/exe
/usr/bin/mise (deleted)

$ ls -l /proc/1577/fd/9
/home/shawn/.cache/mise/lockfiles/3907a6526f68fe81

The old binary still held the pre-#13038 cache-dir lock. The new binary’s doctor looked at ~/.local/state/mise/history/watch.lock, which was empty (flock -n succeeded). Hence DeclaredNotRunning.

Restarting the unit picked up the new binary and the new lock:

systemctl --user restart dev.mise.mise-history.service

After that, /proc/$pid/exe was /usr/bin/mise, fd 9 was ~/.local/state/mise/history/watch.lock, and doctor reported watcher running.

Why the suggested fix is wrong

mise bootstrap services apply converges unit contents and desired state. The unit was already installed, enabled, and running, so apply is a no-op. The mismatch is “running process is an old mise binary / old lock path,” which apply does not detect.

The changelog for #13038 already says existing watchers must be restarted. That never happens on a package replace of /usr/bin/mise, and doctor does not mention a restart.

Suggestions

1. After replacing the mise binary, restart history-watch (systemd user unit / LaunchAgent / Scheduled Task). self-update and package upgrades both leave the old process on a deleted inode.
2. mise bootstrap services apply should restart builtin = "history-watch" when ExecStart’s binary has a different inode/mtime than the running process.
3. Doctor should not say “not running” when the unit is active and health.json is fresh. If the lock path misses, say the watcher is running an old binary and needs a restart.
4. Change the doctor hint from mise bootstrap services apply to a restart, e.g. systemctl --user restart dev.mise.mise-history.service on Linux (and the equivalent on macOS/Windows).

Happy to test a patch. Workaround for anyone hitting this now: restart the user unit; do not keep re-running apply.

[jdx]

This diagnosis is exactly right, and the /proc/1577/exe → (deleted) plus fd 9 on the old cache lockfile is better evidence than I had. Thank you for digging that far.

#13190 addresses suggestions 2 and 3, though not quite the way you proposed.

Suggestion 2 (apply should restart it). Implemented, but the detector is the watch lock rather than an inode/mtime comparison of ExecStart: an apply now restarts a history-watch service whose definition is converged while nothing holds $MISE_STATE_DIR/history/watch.lock. That covers your case and two others an inode check would miss — a watcher wedged or exited while the manager still reports the unit active, and a watcher started with a different MISE_STATE_DIR than your shell uses. It also avoids needing /proc to compare a running process against its unit, which has no good equivalent on macOS or Windows.

It is guarded to the built-in watcher, state = "running", and history.enabled = true, so a watcher you deliberately stopped is left alone.

Suggestion 3 (don't say "not running" when the unit is active). Implemented. Doctor now asks the platform's service manager before concluding anything, and reports the two states separately:

dotfiles: the history service is running but is not watching this store.
     Its process predates this mise version, or uses a different MISE_STATE_DIR;
     edits are not saved automatically until it is restarted.
     Run: mise bootstrap services apply

mise dot status says the same, and --json reports service-not-watching. I used the service manager rather than health.json freshness because a stale process writes fresh health too — your watcher was at health_age_secs: 79 while being the wrong process for the store.

Suggestion 4 (change the hint to a restart command). I kept the hint as mise bootstrap services apply and made it true instead. One portable command beats three per-platform ones in a message that has to name your service, and it keeps working if you renamed the service. On Windows this needed an extra fix: Task Scheduler keeps a running instance across an unchanged registration, so the apply had to ask for the end-and-run explicitly.

Suggestion 1 (restart after the binary is replaced). Not covered, and worth treating separately. pacman replacing /usr/bin/mise cannot notify mise, so nothing can act at upgrade time; the best available is what the PR does — the next mise bootstrap, mise bootstrap services apply, or mise doctor names it and recovers it. mise self-update could restart declared user services, since that path is inside mise. Worth its own issue if that is wanted.

Your workaround stays correct for anyone on 2026.9.5 through 2026.9.8 — restart the unit, don't re-run apply:

systemctl --user restart dev.mise.mise-history.service

If you want to check the patch against your actual setup, git fetch origin fix/dotfiles-watcher-not-watching, build it, and with the old watcher still running confirm that mise doctor reports the new state and that mise bootstrap services apply restarts it rather than reporting it already applied.

AI-assisted — Tool: Claude Code; model: Anthropic/claude-opus-5; version: unavailable.