containerd / docker.io LP: #1870514

[Sergio Durigan Junior]

On Friday, December 04 2020, Paride Legovini wrote:

> Paride Legovini wrote on 04/12/2020:
>> 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.]
>
> The rc?.d files were a leftover from a past docker install (this was
> on my laptop that went through several releases). A *clean* Hirsute
> install behaves just like Focal (= the docker service is stopped after
> a package reinstall). "Good."
>
> These two changes:
>
> https://git.launchpad.net/~paride/ubuntu/+source/docker.io/commit/?h=wants-and-no-stop&id=6ee514e5d842aeb3e7e73d431911888eba20d9b3
>
> https://git.launchpad.net/~paride/ubuntu/+source/docker.io/commit/?h=wants-and-no-stop&id=76e2fc7c50afa78728a3f4d02314701e0a151fd2
>
> fix all the things for me. Build now being published in PPA [1].
> Remember that the first time the fixed package is installed docker
> will still do a restart (= containers will go down), as the *old*
> prerm is called. I think we all agree there's not easy workaround for
> this.
>
> Paride
>
> [1] https://launchpad.net/~paride/+archive/ubuntu/docker-lp1870514

Thanks for consolidating everything we've discussed in a PPA, Paride.

I've verified that the following scenarios work:

1) Pristine Groovy VM + docker.io + redis image running

When I install the package, it does what we expected: it stops the
docker.service, which means that the containers are also stopped.

2) Updated Groovy VM (with the new docker package) + redis image running

When I reinstall docker.io, I can now confirm that the new prerm script
DTRT and *does not* restart docker if the user has opted for that (or if
the user hasn't said anything during installation, which defaults to
"don't restart the docker daemon on upgrades").

I can also confirm that the container is still running after the
reinstallation.

3) Same as (2), but reinsatlling containerd

I can confirm that it is now possible to reinstall containerd without
having docker.service being stopped by the process.  I can also confirm
that the container is still running after the containerd reinstallation.

4) Same as (2), but removing docker.io

I can confirm that it is possible to remove docker.io from the system
successfully.  The running container will be stopped, as it should.
containerd.service will not be affected.

5) Same as (2), but removing containerd

Everything works as expected: when removing containerd, docker.io is
also removed, and all the containers are stopped.

6) Same as (3), but using "--restart always" when creating the redis
container

I can confirm that reinstalling containerd does not impact running
containers whatsoever.

7) Same as (4), but using "--restart always" when creating the redis
container

I can confirm that, in the default case (i.e., the docker service is not
restarted after an upgrade), the container remains running and is not
touched.  I can also confirm that if the user has opted to restart the
docker service after an upgrade, the container is stopped when I
reinstall docker.io, but it automatically restarts when the upgrade
finishes.



These were my findings.  Having said all that, I believe the solution we
reached is the best one, given the circumstances.  Again: when the user
upgrades to the new docker.io package, his/her containers *will* stop
one more time because of the bug in the prerm script.  However, after
that, future docker.io upgrades will honour the "don't restart the
service after an upgrade" setting.

If I think of another possible scenario to test, I will let you know.

Thanks,

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