This article explains the fundamental differences between CRIU and DMTCP (Distributed MultiThreaded Checkpointing), focusing on their architectural approaches to process capture and restoration.
DMTCP implements checkpoint/restore at the userspace library level. To use it, an application must be launched with the DMTCP library dynamically linked (LD_PRELOAD).
glibc wrappers for syscalls), builds an internal shadow database of the process state, and then forwards requests to the kernel.inotify or specific socket types may lack sufficient proxies.CRIU, by contrast, operates primarily from outside the process using standard kernel interfaces (extended where necessary for C/R).
ptrace, /proc, and specialized system calls (e.g., kcmp, map_files) to transparently capture the process state without requiring pre-loaded libraries.Restoring a process tree often requires restoring specific Process IDs (PIDs).
fork(), DMTCP “fools” the application. It intercepts the getpid() call and returns a fake value that matches the original PID. This is highly dangerous, as the application may see inconsistent information in the /proc filesystem (where directories are named by the real PID).ns_last_pid interface or the modern clone3 system call with a specified PID. This ensures that the restored process has the exact same identity as the original, with no inconsistencies in /proc or other kernel interfaces.DMTCP is often easier to deploy on older kernels since it doesn’t require specific kernel support, but it suffers from the inherent limitations and risks of userspace interception. CRIU is the more robust and transparent solution for modern Linux systems, offering faithful restoration of the entire process environment.