k3s systemd Type=notify never signals READY restart blocks forever #170

New issue

Closed

opened 2026-05-28 12:31:47 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-05-28 12:31:47 +00:00

Owner

Found while bringing up the in-cluster registry (#168, channel Q9WR).

Symptom

systemctl restart k3s on kai-server blocks forever; the unit sits in systemd state activating. 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=notify k3s unit runs k3s through a non-exec bash wrapper (k3s-start.sh) under the default NotifyAccess=main, so the child PID's sd_notify READY is dropped (systemd only accepts the notify from the main PID).

Fix

Add NotifyAccess=all to the unit, or exec the 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).

Found while bringing up the in-cluster registry (#168, channel Q9WR). ## Symptom `systemctl restart k3s` on kai-server blocks forever; the unit sits in systemd state `activating`. 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=notify` k3s unit runs k3s through a non-exec bash wrapper (k3s-start.sh) under the default `NotifyAccess=main`, so the child PID's `sd_notify READY` is dropped (systemd only accepts the notify from the main PID). ## Fix Add `NotifyAccess=all` to the unit, or `exec` the 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).

coilysiren referenced this issue from a commit

2026-05-28 13:16:36 +00:00

fix(k3s): add NotifyAccess=all so Type=notify restart doesn't hang

coilysiren closed this issue

2026-05-28 13:16:36 +00:00

coilysiren referenced this issue from a commit

2026-05-28 13:21:29 +00:00

docs(k3s): reconcile #170 notes with the exec fix that landed