22

I have a vanilla install of CoreOS (835.9.0) and it doesn't start the docker daemon on startup. It only starts when I SSH in and do eg docker ps.

How can i make the docker daemon automatically start on system boot?

When i say the docker daemon, i mean ps -ef | grep docker shows no processes until after i do docker ps

37

sudo systemctl enable docker did the trick.

  • 2
    Thanks, and i did read the Docker docs and couldn't find anything to help - i did find a lot about restart policies, but of course they only apply once the docker daemon starts. – Chris Dec 16 '15 at 2:16
  • 6
    Background:The root of this is because docker is socket activated on CoreOS, ie it doesn't block the boot chain. Early versions of docker were slow to start when you had lots of containers on disk which blocked everything that depended on docker from starting quickly, which caused some interesting failures. – Rob Dec 16 '15 at 2:55
  • 4
    Goodness. This drove me mad. Nothing that I read in any of the docs mentioned this. I almost swore off CoreOS in favor of AWS AMI because of it. (AWS AMI automatically starts the Docker daemon by default). – Nostalg.io Aug 15 '17 at 15:10
  • 2
    very unusual for CoreOS to behave this way, given that CoreOS is a dedicated Docker OS and it is not starting docker during boot??? – typelogic Feb 5 '18 at 4:44
  • 2
    This is seriously crucial information. The CoreOS docs do not mention anything about having to enable Docker (or any other container runtime for that matter). Since it is possible to start docker containers on bare CoreOS (and since CoreOS is made to run containers), I was under the impression that was the default. I only realized my mistake when the first update-triggered reboot did not start up my containers. – Florian von Stosch Oct 26 '18 at 11:05
4

This is a bit old now, but I have started using cloud-init to do this on all new servers. I have a saved cloud-init script I use for all my servers. Part of it contains:

#cloud-config
coreos:
  units:
    - name: "docker.service"
      command: "start"
      enable: true

This will enable the docker service and start it on first and each boot.

2

As already explained in this comment by Rob, docker is socket activated. That means that the deamon does not start unless it is called. The existing answers here work, but CoreOS recommends a different approach.

The recommended way to do this, according to the CoreOS documentation is to create a service for your own app which in turn requires the Docker service:

/etc/systemd/system/myapp.service:

[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "trap 'exit 0' INT TERM; while true; do echo Hello World; sleep 1; done"

[Install]
WantedBy=multi-user.target

And have that service start automatically instead:

$ sudo systemctl enable /etc/systemd/system/myapp.service
$ sudo systemctl start hello.service

The example use-case is to update the container to the latest version once the service starts and the advanced example also registers the service in etcd. Read the CoreOS documentation for more background information.

  • That's the "latest" from CoreOS? Docker has had restart policies for years and this approach is not necessary or desirable anymore. It never really was desirable, but it was a workaround for (very old versions of) Docker's lack of support for restarting containers itself. Long past time to stop using CoreOS, I guess... – Michael Hampton Nov 11 '18 at 14:04
  • @MichaelHampton Restart policies also apply when the container crashes for another reason, so one is not a replacement for another. Besides, restart policies do not allow you to update containers on boot, etc. I have no idea which is better, but I suppose this method gives you a little more control. – Neograph734 Nov 11 '18 at 14:52
  • 1
    When you start needing that much control, you also generally need a lot of other bits that are provided by orchestration services: at the simple end docker-compose, all the way up to Kubernetes. – Michael Hampton Nov 11 '18 at 16:18
1

I'm using Docker Swarm, so I don't have a specific app for systemd to be responsible for... I just need docker to start on boot. This is the solution I worked out.

Put this /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

[Service]
Type=oneshot
ExecStart=/usr/bin/docker version
RemainAfterExit=yes

[Install]
WantedBy=default.target

And then just systemctl enable poke-docker to set it up to trigger on each boot, near the end of the startup sequence. The docker version command talks to the docker daemon, triggering the socket and starting the docker service itself.

I tried the systemctl enable docker trick in the other answer, and while it worked at first, it appears to have caused a thundering herd situation of some sort where docker was apparently trying to do a whole lot and failing miserably. I suspect this is the "blocking the boot chain" behavior mentioned in the comments there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.