Docker container doesn't start after reboot with enabling systemd script

10,320

Solution 1

In order to start container after reboot you need to add this property: --restart=always to your container start script. For example: docker run -d -p 80:5000 --restart=always image_name

Solution 2

In my case, I already had the containers set to restart=always (btw you can inspect a container's restart policy with docker inspect -f "{{ .HostConfig.RestartPolicy.Name }}" <container> and/or change it with docker update --restart=always <container>) but the containers still were not starting up until I ran a command like docker ps.

It turns out that the socket was enabled in systemd, but the service itself was disabled and so wouldn't start until a command was issued against it.

Inspecting via systemctl status docker.socket and systemctl status docker.service verified this:

root@poke:~# systemctl status docker.socket
● docker.socket - Docker Socket for the API
   Loaded: loaded (/lib/systemd/system/docker.socket; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-07-30 18:28:38 EDT; 18h ago
   Listen: /var/run/docker.sock (Stream)
    Tasks: 0 (limit: 4647)
   CGroup: /system.slice/docker.socket
   
root@poke:~# systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-07-31 13:19:53 EDT; 5min ago
     Docs: https://docs.docker.com
 Main PID: 3094 (dockerd)
    Tasks: 20
   CGroup: /system.slice/docker.service
           ├─3094 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
           └─3426 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 6379 -container-ip 172.17.0.3 -container-

(Note the "disabled" for docker.service, even though it was running at the time.)

I was able to fix this by running systemctl enable --now docker.service:

root@poke:~# systemctl enable --now docker.service
Synchronizing state of docker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable docker

Many thanks to this reddit user's reply for tipping me off.

Share:
10,320
chip
Author by

chip

Updated on June 15, 2022

Comments

  • chip
    chip almost 2 years

    I have the following systemd script:

    [Unit]
    Description=Hub docker container
    After=docker.service
    
    [Service]
    User=root
    ExecStart=/home/hub/hub.sh
    ExecStop=/bin/docker stop hub
    ExecStopPost=/bin/docker rm hub
    
    [Install]
    WantedBy=multi-user.target
    

    Running the command: systemctl start/stop hub works fine. I also created the symlink by using systemctl enable hub. Why doesn't my service start up after I reboot the entire laptop? I followed the docker guide so that Docker starts up on reboot, but for some reason my container doesn't start up. Am I missing a field in my script?

    The command I am using my ExecStart, "/home/hub/hub.sh" script is:

    docker run --net=host --restart=always --name hub -t hub
    

    After reboot I get the following when I type systemctl status hub:

    ● hub.service - Hub docker container
       Loaded: loaded (/etc/systemd/system/hub.service; enabled; vendor preset: disabled)
       Active: inactive (dead)
    
  • chip
    chip almost 6 years
    I added the restart flag but it still isn't working, this is the docker command I am using in my "hub.sh" script: docker run --net=host --restart=always --name hub -t hub
  • chip
    chip almost 6 years
    Nevermind, it worked. Turns out I forgot to enable the service after I changed the wantedby to multi-user. Thanks so much!
  • Admin
    Admin about 4 years
    Actually I prefer to use --restart unless-stopped
  • Richard Hansen
    Richard Hansen almost 4 years
    This answer tells the user to use Docker's restart management but it looks like the OP wants to use systemd. The Docker docs say, "Do not try to combine Docker restart policies with host-level process managers, because this creates conflicts."