containerd / docker.io LP: #1870514

[Rick Harding]

On Thu, Dec 3, 2020 at 6:49 PM Bryce Harrington <
bryce.harrington at canonical.com> wrote:

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

It looks like we're just talking about bionic+ aren't we?

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

Could this be done in the docker.io update. The idea being that it's the
containerd package that's doing this and a docker.io update could do the
shim work without the need of a 3rd package. This means that we have to
rely on the time difference in the docker vs the containerd release change
to do the best we can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20201204/a6fab80e/attachment.html>