{"version":"2.1.257","anchor":"new-diagnostic-when-a-daemonlock-names-a-pid-this-user-can","canonical_anchor":"new-diagnostic-when-a-daemonlock-names-a-pid-this-user-can","heading":"New diagnostic when a daemon.lock names a PID this user can't signal","tier":"internal","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257\/e\/new-diagnostic-when-a-daemonlock-names-a-pid-this-user-can","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257","markdown":"### New diagnostic when a daemon.lock names a PID this user can't signal\n\nAn unsignalable daemon lock PID is now checked for recycling or predating boot before the lock is replaced as stale.\n\nWhen the supervisor can't signal a process referenced by `daemon.lock` for a reason other than ESRCH, it now checks via a new helper whether the PID is recycled or predates the current boot. If so, it writes a supervisor log line explaining that the lock is being replaced as stale, distinguishing `predates_boot` from a recycled PID belonging to another process.\n\n- Area: Sessions\n- Names: `daemon.lock`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}