On 2019-11-04 23:40, Alexander E. Patrakov wrote:
Hello.
I have tried Podman in Fedora 31. Not a rootless setup.
Software versions:
podman-1.6.2-2.fc31.x86_64 containernetworking-plugins-0.8.2-2.1.dev.git485be65.fc31.x86_64
I have created two containers:
# podman container run -d --name nginx_1 -p 80:80 nginx # podman container run -d --name nginx_2 -p 81:80 nginx
Then I wanted to make sure that they start on boot.
According to RHEL 7 documentation, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomi... , I am supposed to create systemd units. OK, let's take the documented form of the unit and turn it into a template:
[Unit] Description=Container %i
[Service] ExecStart=/usr/bin/podman start -a %i ExecStop=/usr/bin/podman stop -t 2 %i
[Install] WantedBy=multi-user.target
This doesn't work if there is more than one container. The error is:
Nov 04 21:35:57 podman[2268]: time="2019-11-04T21:35:57+05:00" level=error msg="Error adding network: failed to allocate for range 0: 10.88.0.19 has been allocated to ace2de4405205a9a7674a2524cd67c1f0e395a9234b0456c55881a1a4add6019, duplicate allocation is not allowed" Nov 04 21:35:57 podman[2268]: time="2019-11-04T21:35:57+05:00" level=error msg="Error while adding pod to CNI network \"podman\": failed to allocate for range 0: 10.88.0.19 has been allocated to ace2de4405205a9a7674a2524cd67c1f0e395a9234b0456c55881a1a4add6019, duplicate allocation is not allowed" Nov 04 21:35:57 podman[2268]: Error: unable to start container ace2de4405205a9a7674a2524cd67c1f0e395a9234b0456c55881a1a4add6019: error configuring network namespace for container ace2de4405205a9a7674a2524cd67c1f0e395a9234b0456c55881a1a4add6019: failed to allocate for range 0: 10.88.0.19 has been allocated to ace2de4405205a9a7674a2524cd67c1f0e395a9234b0456c55881a1a4add6019, duplicate allocation is not allowed
(as you can see, the conflict is against the container itself)
Apparently different runs of podman need to be serialized against each other. This works:
[Unit] Description=Container %i Wants=network-online.target After=network-online.target
[Service] Type=oneshot RemainAfterExit=yes ExecStart=flock /run/lock/subsys/container.lck /usr/bin/podman start %i ExecStop=/usr/bin/podman stop -t 2 %i
[Install] WantedBy=multi-user.target
Questions:
a) Why isn't some equivalent of this unit shipped with podman? Or, am I missing some package that ships it? b) Why isn't the necessary locking built into podman itself? Or, is it a bug in containernetworking-plugins?
These containers aren't using static IPs, correct? I can recall an issue where static IP allocations were leaving address reservations around after reboot, causing issues... But that should be fixed on the Podman we ship in F31. Otherwise, this sounds suspiciously like a CNI bug. I would hope that CNI has sufficient locking to prevent this from racing, but I could be wrong. Also, you should try using `podman generate systemd` for unit files. Looking at your unit files, I don't think they operate as advertised (`start --attach` can exit while the container is still running, so tracking it is not a reliable way of tracking the container). Thanks, Matt Heon
-- Alexander E. Patrakov _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io