Control: retitle -1 docker.io: please consider restarting when needed Control: severity -1 wishlist Control: tags -1 - unreproducible
On Tue, Oct 17, 2017 at 04:58:41PM -0700, Tianon Gravi wrote: > tags 878912 + moreinfo unreproducible > severity normal > thanks > > On 17 October 2017 at 10:05, Antonio Terceiro <terce...@debian.org> wrote: > > On a completely up to date sid system: > > > > $ docker run -it --rm debian:sid > > docker: Error response from daemon: containerd-shim not installed on system. > > I can't seem to reproduce; created a completely fresh Sid instance, > installed docker.io, and got the following result: > > > The following NEW packages will be installed: > dmsetup (2:1.02.142-1) > docker-containerd (0.2.3+git+docker1.13.1~ds1-1) > docker-runc (1.0.0~rc2+git+docker1.13.1~ds1-2) > docker.io (1.13.1~ds2-3) > golang-libnetwork (0.8.0-dev.2+git20170202.599.45b4086-3) > iptables (1.6.1-2) > libapparmor1 (2.11.0-11) > libdevmapper1.02.1 (2:1.02.142-1) > libip4tc0 (1.6.1-2) > libip6tc0 (1.6.1-2) > libiptc0 (1.6.1-2) > libnetfilter-conntrack3 (1.0.6-2) > libnfnetlink0 (1.0.1-3+b1) > libseccomp2 (2.3.1-2.1) > libsqlite3-0 (3.20.1-2) > libxtables12 (1.6.1-2) > 0 upgraded, 16 newly installed, 0 to remove and 25 not upgraded. > > > $ docker version > Client: > Version: 1.13.1 > API version: 1.26 > Go version: go1.9.1 > Git commit: 092cba3 > Built: Sat Oct 14 16:54:40 2017 > OS/Arch: linux/amd64 > > Server: > Version: 1.13.1 > API version: 1.26 (minimum version 1.12) > Go version: go1.9.1 > Git commit: 092cba3 > Built: Sat Oct 14 16:54:40 2017 > OS/Arch: linux/amd64 > Experimental: false > > > $ docker run -it --rm debian:sid > Unable to find image 'debian:sid' locally > sid: Pulling from library/debian > 3a8649ffa174: Pull complete > Digest: > sha256:58c8f0c963c0813cbad2809a12b1ca9031e3ab5aa31258f2675c65a42475dc23 > Status: Downloaded newer image for debian:sid > root@b9ed033bd019:/# ls -l > total 48 > lrwxrwxrwx 1 root root 7 Oct 9 00:00 bin -> usr/bin > drwxr-xr-x 2 root root 4096 Jun 25 22:19 boot > drwxr-xr-x 5 root root 360 Oct 17 23:54 dev > drwxr-xr-x 30 root root 4096 Oct 17 23:54 etc > drwxr-xr-x 2 root root 4096 Jun 25 22:19 home > lrwxrwxrwx 1 root root 7 Oct 9 00:00 lib -> usr/lib > lrwxrwxrwx 1 root root 9 Oct 9 00:00 lib32 -> usr/lib32 > lrwxrwxrwx 1 root root 9 Oct 9 00:00 lib64 -> usr/lib64 > lrwxrwxrwx 1 root root 10 Oct 9 00:00 libx32 -> usr/libx32 > drwxr-xr-x 2 root root 4096 Oct 9 00:00 media > drwxr-xr-x 2 root root 4096 Oct 9 00:00 mnt > drwxr-xr-x 2 root root 4096 Oct 9 00:00 opt > dr-xr-xr-x 440 root root 0 Oct 17 23:54 proc > drwx------ 2 root root 4096 Oct 9 00:00 root > drwxr-xr-x 4 root root 4096 Oct 9 00:00 run > lrwxrwxrwx 1 root root 8 Oct 9 00:00 sbin -> usr/sbin > drwxr-xr-x 2 root root 4096 Oct 9 00:00 srv > dr-xr-xr-x 12 root root 0 Oct 17 23:54 sys > drwxrwxrwt 2 root root 4096 Oct 9 00:00 tmp > drwxr-xr-x 13 root root 4096 Oct 9 00:00 usr > drwxr-xr-x 11 root root 4096 Oct 9 00:00 var > > > > Have you restarted your Docker daemon since upgrading? If not, it's > likely still running the old daemon referencing the older packages, > and the package tries to be careful about automatically restarting > your daemon because that can cause downtime for your containers. Indeed restarting the daemon did the trick. It seems the package is too careful in this case: this is my workstation where I use docker as a development tool, and during the upgrade I'm pretty sure there were 0 containers running, so the daemon could very well have been upgraded. It would be nice if the restart was automatic at least in cases where there are relevant changes like these recent ones, to avoid this type of confusion.
signature.asc
Description: PGP signature
