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 -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
