k3s systemd Type=notify never signals READY restart blocks forever #170
Labels
No labels
burndown-2026-06
burndown-2026-08
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/advocate
role/director
role/exec
role/frontend
role/gamedev
role/human
role/platform
role/qa
role/science
role/sysadmin
state
ambient
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/infrastructure#170
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while bringing up the in-cluster registry (#168, channel Q9WR).
Symptom
systemctl restart k3son kai-server blocks forever; the unit sits in systemd stateactivating. k3s itself is fully healthy (node Ready, workloads running) - only the systemd readiness signal is lost. Worker had to use--no-block.Cause
The
Type=notifyk3s unit runs k3s through a non-exec bash wrapper (k3s-start.sh) under the defaultNotifyAccess=main, so the child PID'ssd_notify READYis dropped (systemd only accepts the notify from the main PID).Fix
Add
NotifyAccess=allto the unit, orexecthe k3s binary inside the wrapper so the notifying PID is the main PID.Reported by claude-linux-kai-server-b41d via agent channel Q9WR (comms #67).