Container not starting on boot

holgerbauer · February 11, 2021, 12:28pm

Hi everyone.

I try to start a container at boot time using systemd. It follows this guide
I have a container named “unifi”.

CONTAINER ID  IMAGE                   COMMAND           CREATED      STATUS                    PORTS                                                                                                                                             NAMES
0b3b250e03c4  localhost/unifi:6.0.41  /opt/unifi/unifi  12 days ago  Up 1 second ago           0.0.0.0:3478->3478/udp, 0.0.0.0:5514->5514/udp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:8443->8443/tcp, 0.0.0.0:8843->8843/tcp, 0.0.0.0:10001->10001/udp  unifi

I did create a service file.

# /etc/systemd/system/unifi-container.service
[Unit]
Description=Unifi container

[Service]
Restart=always
ExecStart=/usr/bin/podman start -a unifi
ExecStop=/usr/bin/podman stop -t 2 unifi

[Install]
WantedBy=local.target

When I start the container manually with command systemctl start unfi-container it is working fine.
I enabled the service,

$ systemctl status unifi-container
● unifi-container.service - Unifi container
     Loaded: loaded (/etc/systemd/system/unifi-container.service; enabled; vendor preset: disabled)

but after a reboot the container is not started. There’s no error message in the logs and no sign systemd even tries to start the container.

tjdoyle · February 12, 2021, 8:07am

Hi,

I had similar issue to when I tried to start a docker with systemd, in the end I worked round it with a couple of bash scripts; one for start-up & one for stop and called these instead in the service file.

Alternatively there is a podman systemd generator:

github.com

containers/podman/blob/master/docs/source/markdown/podman-generate-systemd.1.md

% podman-generate-systemd(1)

## NAME
podman\-generate\-systemd - Generate systemd unit file(s) for a container or pod. Not supported for the remote client

## SYNOPSIS
**podman generate systemd** [*options*] *container|pod*

## DESCRIPTION
**podman generate systemd** will create a systemd unit file that can be used to control a container or pod.
By default, the command will print the content of the unit files to stdout.

_Note: If you use this command with the remote client, you would still have to place the generated units on the remote system._

## OPTIONS

#### **--files**, **-f**

Generate files instead of printing to stdout.  The generated files are named {container,pod}-{ID,name}.service and will be placed in the current working directory.

This file has been truncated. show original

Thanks Tom.

ersen · February 12, 2021, 8:07am

Is local.target active? What does below command says?

systemctl status local.target

t0xic0der · February 11, 2021, 5:32pm

Did you start your container with the --restart unless-stopped or --restart always flag? That would be correct way of ensuring the your container starts on boot and not using systemctl for the same as your service would first require the Podman socket service to start.

holgerbauer · February 12, 2021, 7:57am

Thanks Tom.

I may use a similar workaround, when I’m not able to go the systemd route.

I’ve tried podman generate, but that service file was also ignored.

holgerbauer · February 12, 2021, 7:58am

Thanks ersen.

I’ve checked this and indeed local.target was not active. I’ve replaced it with multiuser.target and default.target. Didn’t solve my issue though.

holgerbauer · February 12, 2021, 7:59am

Thanks Akashdeep.

I’ve used --restart always.

holgerbauer · February 12, 2021, 8:07am

Your solution worked. The generated service used an active target. I just forgot to enable the new unit.