Skip to content

fix(daemon): a superseded daemon overwrites the shared daemon-shutdown.json #3104

Description

@thymikee

Problem

writeDaemonShutdownReport and clearDaemonShutdownReport write and delete daemon-shutdown.json in the shared state dir without checking who owns it, unlike the daemon.json and daemon.lock paths, which now prove ownership first (#3087).

A daemon that has been superseded still runs its own shutdown, so it can:

  • overwrite the successor's shutdown report with its own, or
  • clear a report the successor still needs.

Both hide why a shutdown happened from whoever is debugging the daemon that is actually serving clients.

Why it is separate from #3087

The issue's completion conditions cover daemon.json only. The fence needs the same reasoning applied to a second shared file, and that file has its own readers whose expectations have to be checked, so it does not belong in the #3087 diff.

Direction

Reuse readRegisteredDaemonOwnership at both sites and decline the write when the record is not match. Note that this file is written by the daemon leaving, so the check is "am I still the serving daemon", not "does this file name me".

Refs #3087, #3102

Activity

  1. thymikee commented on Oct 4, 2026

    @thymikee
    MemberAuthor

    Implemented and verified on main in #3127 (merge 2212eacf5b). Shutdown-report clearing/publication now belongs to the actual acquired registration lock. Each mutation asserts that acquisition is still held; a spent acquisition cannot overwrite a successor report. Startup can clear the prior report while holding the lock before daemon.json is published.

    Real-filesystem controls cover spent acquisition refusal, successor report preservation, startup clearing and release on failed clearing. The final head passed its affected gate and all 21 GitHub checks. Closing this specific report-ownership defect, rather than by association with #3116.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions