I'm about to EOD, so in hopes of keeping activity on the bug cross timezones Rick suggested identifying some specific tasks that'd help move the football down the field on Proposal X.
Robie: The maintscripts I implemented are in the following patch: https://git.launchpad.net/~bryce/ubuntu/+source/containerd/commit/?id=604b72a3543a4e25c8acde692a7ecd6874bd699c Obviously this could benefit from refactoring since I was copy and pasting chunks of logic, but the specific question I want your input on is if you are aware of any dh_* commands or deb-systemd-* commands that would either condense the code or make it more robust. One other more philosophical design question you could help answer. The debhelper generated stuff provided a chunk of code for handling service restart via invoke-rc.d. The question is are there any scenarios where we care about this legacy init system? If there is, then we may need further logic beyond what I've included; if there isn't, then can we omit the update-rc.d / invoke-rc.d logic entirely? Christian: In the above script you can see I am registering reboot-required in certain circumstances. In today's call you mentioned about the possibility of instead of rebooting just requesting a service restart. I was not able to find guidance on exactly how to do that, so wonder if you know more? Can you investigate if that is a viable approach we can do for X/B/F/G/H, or if it is more of a future possibility. While you're at it, you can see I included logic for using the older update-notifier interface. Can you check if that is needed for Xenial? If it isn't we can perhaps drop that. Sergio: Thanks again for demoing the docker commands you were using to test. I've put them in the [Test Case] section of the doc. Unfortunately I get an error running the `docker run` command gives me a permission denied error for OCI runtime create. Obviously my non-docker-fu is making me do something wrong. Can you look at the test case and adjust it to give a more accurately paint-by-number set of docker commands? ------------------------------------------------------------------------ Sergio demoed to me what he and Paride discovered while examining docker.io's prerm file (/var/lib/dpkg/info/docker.io.prerm). Debhelper automatically adds a command to stop the docker service unconditionally: # Automatically added by dh_systemd_start/13.2.1ubuntu1 if [ -d /run/systemd/system ]; then deb-systemd-invoke stop 'docker.service' 'docker.socket' >/dev/null || true fi # End automatically added section This means three things. 1) Proposal A can be crossed off, 2) we might potentially be able to address the problem in docker.io's maintscripts better than in containerd's maintscripts by replacing this debhelper logic with some conditionals like done for Proposal X, and 3) since the user's installed docker.io's prerm gets run before any new package's maintscripts, this means all our proposals suffer the same problem that all of them will result in docker.service getting this 'stop' command at least one time. This third item I'm not sure how we're going to get around, or if we even can. There was an idea expressed early on to introduce a new package with the simple purpose of hackily shimming out this `deb-systemd-invoke stop` call from docker's prerm before doing anything at all with the docker.io or containerd packages. Should we revisit this idea? Or should we simply accept that we're going to trigger the bug for all users one more time in order to get the long term fix in place? Bryce -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
