K3s worker restarter uses k3s.service instead of k3s-agent.service on real k3s clusters

[ernoaapa]

Summary

On real k3s worker nodes using systemd, runtime-class-manager v0.1.0 still tries to restart k3s.service instead of k3s-agent.service.

This is not a custom service name from Hetzner tooling (I'm using hetzner-k3s). It is the standard upstream k3s naming for agent nodes.

Environment

• runtime-class-manager: v0.1.0
• k3s: v1.32.0+k3s1
• cluster provisioning: hetzner-k3s on Hetzner Cloud
• node type affected: worker / agent nodes

Observed behavior

Worker install pods fail after writing the shim and containerd config because the restarter targets k3s.service on worker nodes.

Example log from a worker install pod:

2026/03/12 05:10:44 INFO shim installed shim=spin-v2 path=/opt/rcm/bin/containerd-shim-spin-v2 new-version=true
2026/03/12 05:10:44 INFO runtime config already exists, skipping runtime=spin-v2
2026/03/12 05:10:44 INFO shim configured shim=spin-v2 path=/var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl
2026/03/12 05:10:44 INFO D-Bus is already installed and running
2026/03/12 05:10:44 INFO restarting containerd
2026/03/12 05:10:44 ERROR failed to install error="failed to restart containerd: unable to restart k3s: exit status 5"

A retry pod then completed with:

2026/03/12 05:10:56 INFO shim installed shim=spin-v2 path=/opt/rcm/bin/containerd-shim-spin-v2 new-version=false
2026/03/12 05:10:56 INFO runtime config already exists, skipping runtime=spin-v2
2026/03/12 05:10:56 INFO shim configured shim=spin-v2 path=/var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl
2026/03/12 05:10:56 INFO nothing changed, nothing more to do

So the cluster can converge eventually, but the first worker install job still fails incorrectly.

Why this looks like an RCM bug, not a cluster naming bug

The released v0.1.0 code still hardcodes systemctl restart k3s in K3sRestarter:
https://github.com/spinframework/runtime-class-manager/blob/v0.1.0/internal/containerd/restart_unix.go

Upstream k3s uses k3s.service for servers and k3s-agent.service for agents/workers:
https://github.com/k3s-io/k3s/blob/master/install.sh

I also checked hetzner-k3s, and its worker install logs show the normal k3s-agent.service name, for example here:
vitobotta/hetzner-k3s#487

Expected behavior

On real k3s worker nodes, the restarter should detect and restart k3s-agent instead of k3s.

Related

This looks adjacent to the existing restart / node-installer issues, but seems distinct from k3d-specific handling:

• node-installer(k3d|k0s): job does not terminate properly #393
• node-installer job does not terminate properly #140
• fix(containerd): update restart for k3d scenarios #618

[vdice]

@ernoaapa thanks so much for creating this ticket. I appreciate all of the helpful info.

This makes sense. My k3s lima VM setup was truly minimal; I installed via curl -sfL https://get.k3s.io | sh - which apparently utilizes the k3s name as the systemd service. As you point out, this may not be indicative of the majority of other k3s installations.

I've attempted a fix in #621. I have yet to set up a k3s cluster using k3s-agent. (I tried my best in a single-VM fashion but never got it working.) If you happen to have free cycles, would you be able to test with your setup? I've pushed a node-installer image out there with the fix, if you do: docker.io/vdice/node-installer:k3s-restart, which can be used when installing runtime-class-manager, eg:

helm upgrade --install rcm \
  --namespace rcm \
  --create-namespace \
  --wait \
  --set rcm.nodeInstallerImage.repository=vdice/node-installer \
  --set rcm.nodeInstallerImage.tag=k3s-restart \
  --version 0.1.0 \
  oci://ghcr.io/spinframework/charts/runtime-class-manager

edit: I was able to simulate a multi-node k3s cluster with multiple lima VMs and after updating #621, I can verify that the installer pods exit cleanly (Completed) for both scenarios (server VM running 'k3s' systemd service, worker VM running 'k3s-agent' systemd service). However, if you are able to help test and verify, it would be much appreciated!

[ernoaapa]

Hey @vdice ! Thanks for checking this so quickly.

I'm unable to test it out because I'm using amd64 and looks like you built only linux/arm64.
Any change to build also the linux/amd64? I can test after that in my dev environment.