containerd / docker.io LP: #1870514

[Sergio Durigan Junior]

On Thursday, December 03 2020, Bryce Harrington wrote:

> 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.

Thanks for the email, Bryce.

> 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?

I could not find anything wrong with your docker commands, and I was
able to properly start the redis service here using them.  I don't know
if you're using a container to do this, but I'd recommend using a VM
because of the proper separation between cgroups et al.

> ------------------------------------------------------------------------
>
> 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.

About (2), if we edit docker.io's d/rules and add:

  override_dh_systemd_start:
          dh_systemd_start --package=docker.io -r

then docker.io's prerm script will have:

  # Automatically added by dh_systemd_start/13.2.1ubuntu1
  if [ -d /run/systemd/system ] && [ "$1" = remove ]; then
          deb-systemd-invoke stop 'docker.service' 'docker.socket' >/dev/null || true
  fi
  # End automatically added section

which is what we actually want: prerm will only stop docker.service if
the user is removing the package, but not if it's being updated.

Of course, this doesn't really help mitigate (3), but it does mean that
we won't really need to mess with the maintscript just to get this part
working.

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14