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
About one in five tries, this gives me the wrong (unexpected) result:
$ img=quay.io/libpod/testimage:20200929
$ ./bin/podman run -d --name c1 $imgtrue;./bin/podman run -d --name c2 $imgtrue;./bin/podman ps -a --sort createdfaf3c3ebd4c764dad41ecee6ae0aafb077ef0ae9181f03c05235c8445de779faa381df699c40d4a46f4a678b2758154af375bcb1aee445526171afbf3d9f6e76CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESa381df699c40 quay.io/libpod/testimage:20200929 true 1 second ago Exited (0) Less than a second ago c2faf3c3ebd4c7 quay.io/libpod/testimage:20200929 true 1 second ago Exited (0) 1 second ago c1
I expect to see c1 before c2, always. It's not a timing issue with -d, because c1.Created < c2.Created:
It's not a flake in ps, because for any given run of two containers, podman ps -a --sort created will always return the same order, always always, at least for values of "always" less than a ten-minute while loop.
In every instance when I see this, the CID of c2 is lexically < CID(c1); so much so that it seems improbable (many tens of repeated runs). I don't know if this is helpful. The sorting code looks good to my eye:
In the current code we were translating the created time
from a time.Time to a unix epoch, this was leading to a loss
of precession, and some unexpected results where the sorting
order of containers was misordered because of the precession loss.
If we pass around created as time.Time, we do not loose the precission.
Fixes: containers#8414
Signed-off-by: Daniel J Walsh <[email protected]>
About one in five tries, this gives me the wrong (unexpected) result:
I expect to see c1 before c2, always. It's not a timing issue with
-d
, becausec1.Created < c2.Created
:It's not a flake in
ps
, because for any given run of two containers,podman ps -a --sort created
will always return the same order, always always, at least for values of "always" less than a ten-minutewhile
loop.In every instance when I see this, the CID of c2 is lexically
<
CID(c1); so much so that it seems improbable (many tens of repeated runs). I don't know if this is helpful. The sorting code looks good to my eye:podman/pkg/domain/entities/container_ps.go
Lines 139 to 141 in a18365c
I don't know where else to look; am hoping that someone can take a quick look at the sorting code and see something obvious.
The text was updated successfully, but these errors were encountered: