Closed dkoshkin closed 2 months ago
This systemctl behavior is unfortunate.
Systemctl knows when you need to run daemon-reload
, and in fact, warns you. I think it should do it in your behalf automatically. That's been requested once in the past, and denied. But I think it's worth reexamining upstream.
Because daemon-reload
affects all configuration, so it's best to run at a known "synchronization point," i.e. when you're done adding all drop-ins, not just the ones for containerd. It a relatively expensive operation, so it's best to run it once, if possible.
We can also avoid running it by first checking if it's required for any service whose configuration we've updated. Example:
if [ $(systemctl show containerd -p NeedDaemonReload --value) == "yes" ]; then
systemctl daemon-reload
fi
systemctl restart containerd
For long-term maintenance, I think we might want to factor this out, so that we have this general structure:
For long-term maintenance, I think we might want to factor this out, so that we have this general structure:
- Make any handler that updates the configuration of a systemd service implement ttwo methods: one that updates configuration, and another that restarts the service.
- Call the first method of all handlers.
- Run daemon-reload (to reload configuration possibly updated in the previous step).
- Call the second method of all handlers.
Great idea @dlipovetsky, let me create an issue in this repo. We've gone through a couple of iterations now of this common Contianerd command that's needed by different handlers and moving it out to somewhere more generic makes sense to me.
This systemctl behavior is unfortunate.
Systemctl knows when you need to run
daemon-reload
, and in fact, warns you. I think it should do it in your behalf automatically. That's been requested once in the past, and denied. But I think it's worth reexamining upstream.Because
daemon-reload
affects all configuration, so it's best to run at a known "synchronization point," i.e. when you're done adding all drop-ins, not just the ones for containerd. It a relatively expensive operation, so it's best to run it once, if possible.We can also avoid running it by first checking if it's required for any service whose configuration we've updated. Example:
if [ $(systemctl show containerd -p NeedDaemonReload --value) == "yes" ]; then systemctl daemon-reload fi systemctl restart containerd
Doing a test with this suggestion.
What problem does this PR solve?: During Machine bootstrapping Contianerd drop in files may be added. These files are written to the disk before
preKubeadmCommmands
are run. Always run systemctl daemon-reload along with systemctl restart containerd to pick up these dropins.I saw a warning about the drop-ins when cloud init runs the Containerd restart script, so figured it makes sense to add it here instead of a separate script.
Which issue(s) this PR fixes: Fixes #
How Has This Been Tested?:
Special notes for your reviewer: