Foreword

DSH’s plugin ecosystem follows the philosophy of “everything is a plugin.” The community directory is an independent site and does not equal the official app store.

For DSH users, a specific issue appears after a service restart: the main agent may not know that the service has just restarted, nor why the previous session was interrupted. Existing workarounds might require the user to prompt again, for example by stating that the service has restarted. The plugin introduced below automatically sends a notification at boot, allowing the interrupted work to be continued.

What is this

  • Plugin Name:
edusrez/dsh-smart-restart
  • Maintainer:
edusrez
  • License:
MIT
  • Description: This is a DSH host plugin used to detect whether the DeepSeek Harness service has restarted and to send a Smart-restart notification to the main agent at boot, allowing interrupted work to be resumed.
  • Verified package.json version field:
0.5.1

The verified data does not provide specific changelog notes for this version.

Core Capabilities

Restart Detection

The plugin saves the state of the last boot. The state file path is as follows:

<DSH_HOME>/<stateDir>/marker.json

The file contains the following fields:

{lastBootAt, pid, dshVersion?}

At boot, the plugin compares the PID of the last boot with the current process.pid. If they are different, it indicates that a new process has taken over, meaning the service has restarted. Downtime is calculated using the following formula:

now - previous lastBootAt

The calculation result is clamped to be greater than or equal to 0.

The plugin then writes a new marker for comparison on the next boot.

Boot Notification

On every boot, the plugin sends a Smart-restart notification to the main agent via the source-agnostic agent/session-start hook:

agent/session-start

This hook does not depend on the publication source. For delayed recovery of pinned sessions, the plugin uses a bounded poll to capture sessions that recover slightly later:

750ms tick
~15s cap

Delivery Priority

Notification delivery is processed according to the following priority:

pending-notice.json
shutdown-notice.json
target

Where:

pending-notice.json

Has the highest priority. It is consumed after being read once.

If there is no pending notice, then read:

shutdown-notice.json

This file is also read once and then consumed.

If the shutdown notice does not meet the pin condition, it falls back to:

target

Agent Initiates DSH Restart

v0.2.0 added a tool:

smart_restart

The main agent can call it like this:

smart_restart(reason?)

This step involves the agent initiating a DSH restart and optionally carrying a reason.

The tool first validates the configuration item:

restartUnit

After validation, the tool synchronously writes:

pending-notice.json

This step is completed before the process spawn, ensuring the notification persists after the service is restarted.

Subsequently, the tool generates a detached setsid bash process and executes after a delay of about 1 second:

systemctl restart <unit>

This step is used to trigger a systemd restart even after the current DSH process is terminated.

The tool returns a structure similar to the following:

{ok: true, restarting: true, ...}

On the next boot, the plugin reads:

pending-notice.json

And pins the notification to the session that initiated the call.

Automatic Notification During Normal Restart

v0.3.0 added coverage for normal restart scenarios.

When the process receives the following signals:

SIGTERM
SIGINT

The previous process writes:

shutdown-notice.json

The file records the last active session and a timestamp.

At boot, if there is no:

pending-notice.json

The plugin reads:

shutdown-notice.json

If the last active session recorded remains active within the time configured by:

shutdownGraceMs

The plugin pins the notification to that session.

Otherwise, delivery falls back to:

target

Therefore, when a normal systemctl restart occurs while the agent is active, the notification can be received at the boot of that session without requiring extra user prompting.

Canary Pre-restart Gate

v0.4.0 supports an optional canary pre-restart gate.

When enabled, the plugin first starts a temporary DSH instance to verify the startup result. If the temporary startup fails, the restart is aborted.

v0.5.0 supports automatic detection of the systemd unit from the following path:

/proc/self/cgroup

This allows the smart_restart tool and the canary to achieve zero configuration in systemd-managed installs.

Installation and Dependencies

The verified data did not provide the original Install command, so this article does not provide an installation command. It is recommended to check the installation instructions in the directory page or GitHub repository before installing.

The plugin declares the following peerDependencies:

@deepseek-ai/cordis ^4.0.1
@deepseek-ai/dsh-agent ^0.1.0-rc.7 || ^0.1.1-rc.0
@deepseek-ai/dsh-llm ^0.1.0-rc.7 || ^0.1.1-rc.0
@deepseek-ai/dsh-session ^0.1.0-rc.7 || ^0.1.1-rc.0
@deepseek-ai/dsh-home-paths ^0.1.0-rc.7 || ^0.1.1-rc.0
@deepseek-ai/dsh-tools ^0.1.0-rc.7 || ^0.1.1-rc.0

The plugin is a self-contained single-host bundle and does not rely on external services.

Typical Usage

Agent Initiates Restart

  1. Agent calls:
smart_restart(reason?)
  1. Tool validates:
restartUnit
  1. Tool synchronously writes:
pending-notice.json
  1. Tool generates detached setsid bash process, and executes after a delay of about 1 second:
systemctl restart <unit>
  1. Tool returns:
{ok: true, restarting: true, ...}
  1. On the next boot, the plugin reads:
pending-notice.json
  1. Plugin pins the notification to the session that initiated the call.

Normal Restart During Active Agent

  1. Process receives:
SIGTERM
SIGINT
  1. Previous process writes:
shutdown-notice.json

  1. At boot, the plugin reads this file in the absence of a pending notice.

  2. If the last active session recorded is active within:

shutdownGraceMs

The notification is pinned to that session.

  1. Otherwise, the notification falls back to:
target

Applicable Scenarios and Notes

Suitable for the following scenarios:

  • DSH instances are interrupted due to service restarts;
  • You want the main agent to know that the service has just restarted after boot;
  • You want the agent to continue processing unfinished tasks after a restart;
  • You want normal systemctl restart to deliver notifications to the corresponding session;
  • You want to use a canary for a temporary startup verification before restarting.

Note the following points:

  • The plugin runs as a DSH host plugin and accesses state files and system commands with the current dsh process permissions;
  • Check source code, dependencies, and license before installing;
  • The canary starts a temporary DSH instance; confirm that the current environment allows this before enabling;
  • v0.5.0’s systemd unit auto-detection depends on /proc/self/cgroup and applies to systemd-managed installs.
  • The verified data did not provide the official install command original text; do not concatenate install commands from the repository name.

Links

  • Directory page:
https://www.skillhub.cn/plugins/edusrez/dsh-smart-restart
  • GitHub repository:
https://github.com/edusrez/dsh-smart-restart