Change:
systemd.services.k3s = { description = "k3s service"; <del> after = [ "network.service" "firewall.service" ]; wants = [ "network.service" "firewall.service" ]; </del> <ins> after = [ "firewall.service" "network-online.target" ]; wants = [ "firewall.service" "network-online.target" ]; </ins> wantedBy = [ "multi-user.target" ]; path = optional config.boot.zfs.enabled config.boot.zfs.package; serviceConfig = {

Discussion:
Describe the bug doesn't depend on , which introduces a race and causes spurious errors. the service doesn't actually stop the containers, so when shutting the system down we get . This causes the shutdown time to go through the roof. Additional context Kind of related to because could be useful for 2. Notify maintainers Nonetheless, thanks for maintaining this!
For number 2, would not a be enough in the service unit?
was most likely copied from and because is the default (according to ) I believe it's there for a reason. I still gave it a shot: defined my own service using . Instead of complaining about this gives us the standard systemd 1m30s timeout countdown. I'll make a PR with the network part for 1 as that does work.
Yup, it was copied from k3s.service. I think the reason it's there is that often, if you just do something like , it's desirable for the containers to keep running since k8s can "re-adopt" those orphaned containers. It does sound like it interacts poorly with shutdowns, but for things like k3s upgrades, it seems desirable. I'm not sure the right solution there. For the networking thing, I definitely think we want an after=network- Probably a simple miss on my part. I use the module with , which sets , which as a side-effect orders it after , which is why I think I haven't been impacted by that yet. One other thing that sorta falls under this issue: should also be ordered after on nixos to ensure the kube-proxy iptables rules don't race with the nixos fw rules on bootup. This is something I realized a few days ago, and hadn't gotten around to fixing.
I agree, I noticed when I reverted back to just now, waited for the containers to stop. I that to the PR. I only saw your comment after submitting it. How about adding and using it in ( is called for restarts too)? It's not perfect because this means one more file to keep in sync with upstream, but I don't see a better solution.
2 is affecting docker too on 21.05.
Yes, this is pretty annoying. I wish that issue would get more attention (by the containerd folks).

Came here to link this, it costs 20-30s per reboot
I ran into the "shutdown blocked on containerd-shim" message by way of forgetting about containers I'd previously run. I had some a container which I'd run and then forgot about. IIRC, even having stopped containers means that containerd-shim will time out on shutdown/reboot. In my case, I didn't need to keep the container around between reboots. So, I was able to work around the timeout by just removing the containers. -- But if you've forgotten about it, you wouldn't know to look.
I ran into it by having a server I intended to reboot get stuck, waiting for containerd-shim forever. It did not time out. This happened after the network had been torn down, so there was no way to fix it until I got back from vacation. RIP all my planning. Destroying containers prior to shutdown isn't a good fix. The user might forget, or -- quite possibly -- might still want those containers to exist after the reboot. This arguably is indeed a bug in the docker service, but also in however reboots are configured. Nothing should be able to block a reboot indefinitely.
I assume will fix this?
I'm wondering if this gets merged to containerd before we release 22.05. ;)
The second workaround in this SO answer is just a systemd unit so I wonder if we could integrate that if they do not get this merged by then.
Merged! Unfortunately the diff does not apply cleanly to 1.5.9.
Looks like this has been backported to the 1.5 branch:
At least the shutdown issue seems gone on 22.05. The other issue seems to be solved by - closing.
From what I can tell, I still have this issue. Running on . I can confirm that my k3s.service file is the same as in