Container not starting on boot

Ask Fedora
, , ,
1

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.

3 Likes
2

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:

Thanks Tom.

5 Likes
3

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

systemctl status local.target
2 Likes
4

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.

1 Like
5

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.

6

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.

1 Like
7

Thanks Akashdeep.

I’ve used --restart always.

8

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

2 Likes
9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.