checkpoint & restore container's time namespace

[gxxxh]

I find that criu will restore container in a new time namespace, which can make sure the container's process can see the same monotonic time between checkpoint and restore process.
However, from container's view, there are two api include CreateContainer and StartContainer, we call criu restore to restore container's time ns in CreateContainer, but when we call StartContainer, the time ns has already move forward for a while. It means, after container restore, The time must have moved forward slightly from when the dump was performed.
This time shift might cause anomalies in container processes. How do you perceive this change? Are there any viable solutions?
@adrianreber

[cyphar]

I don't think there is an ideal solution for this -- you cannot change timens offsets as soon as any program is forked inside the timens. It is possible for a process to get frozen and thawed and experience the same behaviour, so this isn't criu-specific.

[gxxxh]

I have another question here, why we using cgroup freezer to pause and resume containers, instead of using sigstop and sigcond?

[cyphar]

cgroup freezing (especially in cgroupv2) is far more reliable than SIGSTOP. You really couldn't practically use SIGSTOP for freezing containers -- not to mention that managing SIGSTOP of all processes in a cgroup would not be practical. This is the same reason why cgroup.kill is preferable to sending SIGKILL (and SIGKILL is the most reliable signal, followed by RT signals).

[gxxxh]

I don't think there is an ideal solution for this -- you cannot change timens offsets as soon as any program is forked inside the timens. It is possible for a process to get frozen and thawed and experience the same behaviour, so this isn't criu-specific.

Thanks for the answer. Another question here,
We perform checkpointing as a one-time, atomic operation. However, during restoration, we have to reuse the create and start interfaces, which introduces a time gap. Why wasn't restore also implemented as a separate interface from the beginning?

Although container runtimes provide pause and resume interfaces, from the user's perspective, they may not want their containers to be paused for a period of time. This makes the checkpoint and restore process still noticeable to users. Moreover, the use of monotonic time could potentially cause issues in some processes after restoration (for example, Go routines that rely on sleep based on monotonic time might experience scheduling problems after being restored).

[adrianreber]

Are you talking about runc? runc only has the restore call. Kubernetes does create and start to restore a container.