containerd / docker.io LP: #1870514

[Paride Legovini]

Sergio Durigan Junior wrote on 04/12/2020:
> On Thursday, December 03 2020, Bryce Harrington wrote:
> 
>> ------------------------------------------------------------------------
>>
>> 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.

I agree with Sergio's findings. In the docker.io packaging we just need 
to do both of:

- use Wants= instead of BindsTo=
- add the suggested override_dh_systemd_start to d/rules

Note that we need the override *in any case*, as at the moment an update 
of docker will cause docker to restart and running containers to go 
down. This is at least as important as the "original" containerd issue.

You can verify that it's broken by doing this on a system where docker 
is already installed (from the archive, no PPAs, tested on Focal and 
Hirsute):

1. Start a container, e.g.
    docker run --rm -d squeakywheel/nginx:edge
2. Verify it's running via `docker ps`
3. Reinstall docker: `apt install --reinstall docker.io`
4. Check `docker ps` again. The container will be DOWN.
    [Focal and Hirsute behave differently here. In Focal the
     docker service will be down after the reinstall, in
     Hirsute it goes down and then back up automatically.
     This is because the Hirsute package installs
     /etc/rc?.d/*docker links (!). Investigating.]

In other words the debconf no-restart setting is broken.

With Sergio's override_dh_systemd_start this is fixed.

With the BindsTo -> Wants change, we fix docker going down when 
containerd updates/restarts/stops/whatever.

I feel like I'm insisting, but if this works it would basically be a 
3-line diff to fix the thing, so I think it's worth trying. :)

Paride