Hello Adam, all,
Adam Williamson [2023-02-21 9:02 -0800]:
What about Cockpit, which is also shipped in the default setup?
I was going to say that, but then I thought, this is about shutdown policy; is it really a big problem if Cockpit doesn't shut down cleanly?
No, it isn't. Brittle as network connections are, we design cockpit with a "no long-running operations tied to the cockpit session" rule in mind. Any such operations, like creating a file system, applying updates, or starting a VM or container are done only as control messages to their respective system services (udisks2, packagekit, libvirt, and podman). You can disrupt the network, disconnect the cockpit session, reconnect later, and the UI picks up the current state.
IOW, there should be no reason why shutting down cockpit.service takes longer than a few milliseconds.
AIUI the question is "which services do we need to make sure we wait for to close down cleanly, rather than just killing them if they haven't shut down in some rather short period of time".
Full ack. There should be very few of these.
Thanks,
Pitti