This message was deleted.

The linked KB is for rke1, it says use the included scripts for rke2

I’m not aware of any problems with the uninstall script. If you find any, please open an issue

Hi @creamy-pencil-82913, circling back to this. after integrating some time my only concern about

rke2-killall.sh

is that it's sometimes too slow for my environment's needs. So far I've seen it run for up to 20-30 seconds and I'm looking for a faster ungraceful way to cleanup the host for some scenarios. AFAICT the majority of the time is spent on

killtree

. 1. Should I be concerned about performing SIGKILL on

kubepods.slice

, before running

rke2-killall.sh

? 2. Should I be concerned about running rke2-server/agent.service under a new slice ("`rke.slice`"), and also use SIGKILL for it? AFAICT killing just that slice without killing

kubepods.slice

would break the pstree expected by

rke2-killall.sh

(processes like

etcd

which are childs of

containerd-shim

and will not be discovered by the script) Thanks!

in what scenario is 30 seconds to kill and unmount everything too slow?

This isn't about k8s functionality but about the requirements of the environment that it's embedded in, which is accustomed to these kinds of cleanup happening as fast as docker kill. Since this is not the possible in the case of rke2, I'm looking for ways to speed this up as much as I can.

there aren’t any intentional delays or sleeps here, you can look at the script yourself but it is literally just killing and unmounting as fast as it can. Kubernetes does a lot more than Docker, it takes more time to clean it up.

I understand, and I'm trying to add more logs there to get more information, but my current impression is that

killtree

can be done faster, maybe it's the fact that

pstree

it's recursive.

i haven’t tried it but you’re welcome to do so and let us know how it goes!

Definitely. My only concern about it was messing with the parent-child process relations in a way that

pstree

will miss processes but from my experiments this isn't the case. Thank you!