Call for testing of the docker snap

Interesting – in my reading of https://snapcraft.io/docs/removable-media-interface, this seems very similar to the home interface we already include (and indeed, I found those docs via https://snapcraft.io/docs/desktop-interfaces, where home is also listed :sweat_smile:), so from that perspective it seems like a reasonable interface for us to allow/include.

The other half of this (allowing --data-root to be on removable storage) seems a bit more complex though, especially how we’ll have to handle existing installs vs new installs to make it work properly. :disappointed:

Perhaps there’s enough value in including the first half (adding the removable-media interface) without committing to the second half until we can come up with a clean and reliable way to support both existing installations and new installations?

Agreed, I think adding removable-media is very cheap and easy to do, but allowing to set --data-root is more complex, since you can’t just add it to the daemon.json and remove it from the args set in the daemon, as for existing installs that don’t have the data-root set in the daemon.json you would be breaking them. What you could try to do is have some kind of jq check to see if data-root is set inside the daemon.json and if it is not then add the --data-root arg to the daemon command line before running, otherwise don’t add it and then you it will use the daemon.json. This allows you to update the daemon.json file in $SNAP to specify data-root and have this change automatically work for new installs of the docker snap.

Yeah, I’ve deferred on that implementation for now (since it’s bound to have unforseen edge cases when we finally do it) – however, 19.03.11 is in the candidate/beta/edge channels now and includes removable-media. :+1:

2 Likes

Not sure if you’re still interested, but see Docker: docker-compose in swarm mode give ro filesystem

I’m using the current docker snap (19.03.11) and had several “bind: address already in use” issues. One false positive is in case you have host OS level services running in the background which use ports you map with docker ports. In case stopping host level services does not help I could resolve issues with docker rm -fv $(docker ps -aq) # Remove all containers, sudo snap remove docker --purge and sudo snap install docker.

can you provide more logs? was dockerd failing to bind to an address or was it something within the container that was failing to bind to an address ?

Unfortunately I had this issue in a non-producible manner. Cause I had to use purge the logs are probably gone. Or are they still persisted somewhere?

if the logs are there, try journalctl -e --no-pager -u snap.docker.dockerd

In case I discover this issue again I’ll provide the log output.

Hi folks, just a note that the docker snap now has a new maintainer @tianon who is maintaining it at github.com/docker-snap/docker-snap instead of Launchpad, so please file issues there.

I would edit this post to reflect that and point folks there, but I can’t seem to edit my original post anymore.

1 Like