Understanding the RKE2 systemctl service in failed state

An RKE2 cluster

When managing RKE2 clusters, users may notice that stopping RKE2 services using systemctl results in a failed systemd service state. This article explains why this happens, what it means, and how to properly shut down RKE2 processes to avoid confusion or lingering components.

Users observed the following behavior:

• When running systemctl stop rke2-server on a master node or systemctl stop rke2-agent on a worker node, the service enters a failed state.

• Despite the service being marked as "failed," some processes such as containerd and pods continue to run.

• Attempting to kill the main process PID directly does not cleanly stop the related components.

To fully and cleanly stop all RKE2-related processes and containers, including containerd, use the rke2-killall.sh script. This script is designed to:

• Terminate all RKE2 processes

• Stop containerd and associated workloads

• Prevent residual resource conflicts when restarting or upgrading

This behavior is expected and by design. RKE2 does not perform a graceful shutdown when stopped via systemctl. Instead:

• RKE2 exits abruptly, returning an exit code of 1 rather than 0. When the process exits, it takes the kubelet and containerd with it.

• This non-zero exit code causes systemd to mark the service as failed.

• The reason for the abrupt shutdown is to speed up upgrades by leaving containerd and running workloads intact until explicitly cleaned up.