33

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

Improve this question
0

4 Answers 4

Reset to default
55

sudo systemctl enable docker did the trick.

Improve this answer
10
  • 3
    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, 2015 at 2:16
  • 7
    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, 2015 at 2:55
  • 7
    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, 2017 at 15:10
  • 3
    very unusual for CoreOS to behave this way, given that CoreOS is a dedicated Docker OS and it is not starting docker during boot???
    – daparic
    Feb 5, 2018 at 4:44
  • 4
    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, 2018 at 11:05
6

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.

Improve this answer
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.

Improve this answer
3
  • 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, 2018 at 14:04
  • 1
    @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, 2018 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, 2018 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.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .