+++ This bug was initially created as a clone of Bug #1166076 +++ Description of problem: Docker service is not starting during boot of Atomic image of Fedora 21 as it is not enabled in systemd. bash-4.3# systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled) Active: active (running) since Thu 2014-11-20 10:43:03 UTC; 47min ago Docs: http://docs.docker.com Main PID: 907 (docker) CGroup: /system.slice/docker.service └─907 /usr/bin/docker -d -H fd:// --selinux-enabled --storage-opt dm.fs=xfs --storage-opt dm.datadev=/dev/atomicos/docker-data --storage... Version-Release number of selected component (if applicable): Fedora-Cloud-Atomic-20141112-21.x86_64.qcow2 How reproducible: Always Steps to Reproduce: 1. use Fedora-Cloud-Atomic-20141112-21.x86_64.qcow2 to boot. 2. check if docker service is running 3. Actual results: Expected results: Additional info:
I know it seems odd but I think the reasoning is so that you can configure the storage how you want it before the docker daemon starts (and configures storage automatically in a suboptimal way). The desire is for you to configure storage and then enable docker.service. I think the rationale is that customers will be happier with better performing storage and would prefer that over the one step they have to take to configure and enable the docker service on start. We need to make this easier to understand though (either through documentation, notification, or coming up with a new design). A couple of options: - Document this behavior and promote it. - Create an MOTD that gets displayed on first log in - Actually enable docker.service.. but make docker run after docker-storage-setup.service. This would *require* users to use docker-storage-setup to configure storage (or some script they injected during cloud-init) unless they explicitly disable docker.service during cloud-init. Thoughts? What can we do better?
Or wrap "storage-setup", "enabling docker service" and wherever comes in future for the setup in a single command. So before deploying we can just run it and be done with the setup of Atomic.
Think my vote is for "Actually enable docker.service. but make docker run after docker-storage-setup.service". Let's aim for something useful and working out of the box even if it means expressing opinions about how to do things.
Colin, perhaps you're the right owner of this bug? I heard Alex moved on to other things (maybe I heard wrong)
Further discussion - Docker does the right thing (e.g. starts when you do a "docker pull" or whatever) - it's just not "running" according to systemctl I think this is NOTABUG because if you're running Atomic you should expect it to work, I wouldn't expect to need to check its status unless I run into an error, etc.
Right, docker starts when you do a "docker pull" or whatever. But if you see from systemd point of view, the status from systemctl is irrelevant which is odd and not consistent with other services.
Lalatendu, The "docker.socket" unit is enabled on a fresh install from the 2014-11-12 image: # systemctl status docker.socket ● docker.socket - Docker Socket for the API Loaded: loaded (/usr/lib/systemd/system/docker.socket; enabled) Active: active (listening) since Thu 2014-11-20 16:08:17 UTC; 5min ago Listen: /var/run/docker.sock (Stream) With a fresh install from the 2014-11-12 image (1877f1fa64), "docker.socket" is enabled when the system first boots, so there doesn't appear to be a problem here: # systemctl list-units | grep docker docker.socket loaded active listening Docker Socket for the API The service will activate when a client connects. With an image upgraded today (2014-11-20 10:32:27 1646d717e9), both the socket and service appear to be enabled and active at boot: # systemctl list-units | grep docker docker.service loaded active running Docker Application Container Engine docker.socket loaded active running Docker Socket for the API
Some new information has come to light. I think (long term) we should somehow get the docker service enabled as when users see that it is disabled it raises questions and we get bug reports. It is expected behavior that a daemon should be running before a user can use the service (i.e. libvirtd must be running in order to use virsh). Short term this isn't really a problem though (as far as functionality goes). The docker executable will start the docker daemon if it isn't already running on the system. This means anytime you execute docker it will start the docker daemon. For this reason the service doesn't really need to be enabled at all. I verified that adding a systemd unit file (i.e. /etc/systemd/system/owncloud.service) to run a docker container on boot also started the docker daemon. An interesting note about this though: typically in my unit file I have "After=docker.service". I can't do that in this case unless I enable the service.
@Lars Kellogg-Stedman Hey, I again crossed checked with a fresh image of Fedora-Cloud-Atomic-20141112-21.x86_64.qcow2 and "systemctl status docker" tells me disabled. Not sure how you are different results. can you please put more details?
Colin is this fixed now?