containerd / docker.io LP: #1870514

Bryce Harrington bryce.harrington at canonical.com
Thu Dec 3 23:47:53 UTC 2020


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



More information about the ubuntu-server mailing list