You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating init containers in a pod using podman kube play, they are created in the order specified in the YAML spec. When they are run, the are run in order of creation time (oldest first, newest last). However, in rare circumstances, these orders are not the same. If the system time changes during pod creation, for example a system service pod starts up concurrently with the system time daemon, the system time can change while init containers are being created. If the system time is sent into the past, then the later init containers could have creation times after the earlier init containers, causing them to run first.
This is a big problem if the init containers have to run in order in order to behave correctly.
Here is where containers get their creation time set -
This happened in a vCenter virtualization environment where VMs boot with a time that was slightly too far in the future, and the time is corrected by ntpd during pod creation. Doesn't happen every time, just some. When this happens a critical service running in a podman pod does not start correctly because critical functions performed by init containers are performed out of order.
Additional information
No response
The text was updated successfully, but these errors were encountered:
@baude, should we store each init container's position in the spec definition and use that to sort the init containers?
Otherwise, I don't see any immediate way to do it with what we currently have.
Yes I think the only way is to store the order explicitly, maybe we can hack it into the annotations or we add a new field to the container config.
Although I think we use the time for much more things, for off display in podman ps/inspect. But also to calculate avg cpu based on it for things like stats so there are quite a few things that can be wrong if the time is changed.
Issue Description
When creating init containers in a pod using
podman kube play
, they are created in the order specified in the YAML spec. When they are run, the are run in order of creation time (oldest first, newest last). However, in rare circumstances, these orders are not the same. If the system time changes during pod creation, for example a system service pod starts up concurrently with the system time daemon, the system time can change while init containers are being created. If the system time is sent into the past, then the later init containers could have creation times after the earlier init containers, causing them to run first.This is a big problem if the init containers have to run in order in order to behave correctly.
Here is where containers get their creation time set -
podman/libpod/runtime_ctr.go
Line 212 in afe55cd
Here is where containers are retrieved from podman state in creation time order -
podman/libpod/pod.go
Lines 502 to 518 in 67bbbb9
Here is where containers are started in retrieval order -
podman/libpod/pod_api.go
Lines 20 to 27 in afe55cd
Steps to reproduce the issue
Send system time backwards while concurrently creating a pod with multiple init containers.
Describe the results you received
Here is an example:
Describe the results you expected
init containers should run in the specified order - A, then B, then, C, then D
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
This happened in a vCenter virtualization environment where VMs boot with a time that was slightly too far in the future, and the time is corrected by ntpd during pod creation. Doesn't happen every time, just some. When this happens a critical service running in a podman pod does not start correctly because critical functions performed by init containers are performed out of order.
Additional information
No response
The text was updated successfully, but these errors were encountered: