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
Problem
writeDaemonShutdownReportandclearDaemonShutdownReportwrite and deletedaemon-shutdown.jsonin the shared state dir without checking who owns it, unlike thedaemon.jsonanddaemon.lockpaths, which now prove ownership first (#3087).A daemon that has been superseded still runs its own shutdown, so it can:
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.jsononly. 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
readRegisteredDaemonOwnershipat both sites and decline the write when the record is notmatch. 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