fix(bootstrap): never stop the dashboard from inside its own systemd cgroup

A plugin self-update took the dashboard down and left it down. The chain
ran correctly up to the point where the bootstrap SIGTERMs the server it is
replacing — and that server was systemd-managed, with the bootstrap running
as its descendant, i.e. inside its cgroup. Two failures fired at once:

  * the server exits 0, and `Restart=on-failure` reads a clean exit as
    "meant to stop", so systemd did not bring it back;
  * `KillMode=control-group` reaped the bootstrap itself, mid-run, before it
    could repoint the unit at the new plugin root or write state.json.

Evidence from the incident: bootstrap.log ends at "stopped the server
started from the previous plugin version" with no systemd line after it,
.bootstrap.lock survived with a dead pid, state.json still named the
previous version, and the unit's ExecStart still pointed at the old cache
dir. The same truncation is visible on three earlier updates — those only
recovered because a later SessionStart bootstrapped again.

systemd-service.js now splits install into writeUserService (repoints the
unit, starts nothing) and restartUserService (--no-block). The bootstrap
skips the manual stop whenever a unit of ours owns the server, and defers
the restart past writeState and releaseLock, so being killed by its own
request costs nothing. The unit is Restart=always: a graceful SIGTERM from
anything must no longer read as "leave it stopped".

installUserService keeps its old semantics for `agenthub service install`,
which runs from a user's shell and is not in the cgroup.

This commit is contained in:

nntrivi2001

2026-09-11 16:30:10 +07:00

parent 0335e0e6bc

commit de8d1079e0

6 changed files with 334 additions and 38 deletions

									
										docs/DEPLOYMENT.md
									
		+4
		-1
	
												View File
												
				@@ -456,7 +456,10 @@ Environment=NODE_ENV=production

				Environment=PORT=4820

				Environment=DASHBOARD_DB_PATH=/var/lib/agenthub/dashboard.db

				ExecStart=/usr/bin/node server/index.js

				Restart=on-failure

				# `always`, not `on-failure`: a graceful SIGTERM exits 0, which `on-failure`

				# reads as "meant to stop" — one stray kill and the dashboard stays down.

				# `systemctl stop` still stops it. Same reasoning as the plugin's own unit.

				Restart=always

				RestartSec=10

				StandardOutput=journal

				StandardError=journal