"Matt,
no, I don't use static IPs. I let podman allocate them. I have already
tried `podman generate systemd` as per earlier suggestion.
The issue is definitely not with stale reservations persisting across
a reboot, otherwise adding "flock" would not have helped.
Regarding the "`start --attach` can exit while the container is still
running comment: if it is true, please ask the appropriate person to
fix the systemd unit example in RHEL7 documentation.
вт, 5 нояб. 2019 г. в 01:19, Matt Heon <mheon(a)redhat.com>:
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_atomic_host/7/html/managing_containers/running_containers_as_systemd_services_with_podman
>, 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(a)lists.podman.io
>To unsubscribe send an email to podman-leave(a)lists.podman.io
--
Alexander E. Patrakov