CRIU (Checkpoint/Restore In Userspace)

CRIU operates by attaching to a target process tree via ptrace, walking /proc/[pid] to enumerate memory mappings, file descriptor tables, credentials, signal handlers, and namespace membership, then dumping this state into a set of structured image files. Restore reverses the process: a new set of tasks is forked, memory is mapped back into place, file descriptors are reopened or re-fd’d via SCM_RIGHTS tricks, and namespaces are reconstructed before execution resumes at the exact instruction pointer. Critically, this happens without any cooperation from the application — it works on arbitrary binaries, interpreters, and JIT-compiled runtimes, which is what distinguishes it from application-level serialization.

In container ecosystems, CRIU is exposed through runc checkpoint/restore and containerd’s checkpoint API, and surfaces in Kubernetes as an alpha-stage ContainerCheckpoint kubelet API. Practical use cases include node-drain-safe migration of long-running stateful batch or ML training pods, warm-starting large JVM or interpreter-heavy workloads to eliminate cold-start JIT/warmup cost, and forensic capture of a live compromised container image for offline analysis without killing the process (preserving evidence that a simple kill -9 would destroy).

The failure surface is dominated by kernel and hardware coupling. TCP sockets require kernel TCP_REPAIR support and careful handling of in-flight packets; restoring across mismatched kernel versions, differing CONFIG_* build options, or different CPU microarchitectures (vDSO, CPU feature flags) can produce a process that dumps clean but crash-loops or silently corrupts state on restore. GPU contexts, most hardware-mapped I/O, and kernel-unsupported socket families (some AF_UNIX edge cases, certain netlink sockets) are frequently unrestorable, which rules out naive checkpointing of GPU-bound inference or training pods without vendor-specific driver support. CRIU also requires elevated privileges (CAP_SYS_ADMIN, PTRACE access), which has direct security implications in multi-tenant clusters — checkpoint images themselves are effectively a full memory dump and must be treated as sensitive material (encrypted at rest, access-controlled) since they can contain secrets, TLS keys, or credentials resident in process memory at dump time.

Architecturally, CRIU shifts checkpoint/restore from an application concern to a platform concern, but it does not eliminate the need for application-level consistency guarantees — a process frozen mid-transaction with an open distributed lock or in-flight RPC will resume in that same inconsistent state, so it composes poorly with protocols that assume liveness-bounded leases or fencing tokens unless those are explicitly drained before dump. Teams adopting it for live migration need to treat it as an OS-level primitive layered underneath, not a replacement for, application-aware graceful shutdown and reconciliation logic.