The reason for wait_for_container is to avoid races in tests between detached container runs and operations on the detached container. I don't have a problem with removing them from the checkpoint/restore tests if you're sure they're not necessary but I'm fairly sure that we do need them for most of the other tests.

@cyphar I think I don't understand the problem. Could you give more details?

Do you want to say that "runc run -d test" exits before the container achieves the running state? It sounds weird.

Cc: @mikebrow

@cyphar I tried to put sleep in different places and everything works fine.

Hmmm, okay. I'm wondering if this is something that we fixed after the --console-socket changes (where init will block until the socket is sent) and thus we no longer have races like that. In which case, I'm fine with dropping it.

I do recall that there were issues in the past when we didn't have wait_for_container but those issues have been resolved, I guess.

@cyphar thank you for the feedback. I think that we want to detect this sort of issues in future, so it probably better to remove this hack.

yeah the wait stuff was to get around the timing feature where runc run (might have just been detached cases?) would return before the container can be managed with a subsequent runc call. If the call is fully synchronous now the feature is broken and we can delete the waits :-)

@mikebrow Yeah, that "feature" sounds like a bug to me. We should drop it then IMO. In addition I've recently found a bunch of race conditions in our state transition code that we'll need to sort out as well.

LGTM.

LGTM