This article describes what application can do to make CRIU refuse to dump it, summarizing our experience in the area. Note that there is no "What cannot be restored" article, and never will be. Is something was dumped, it should be restored.
Some things cannot be dumped at all, some require special option to be used.
Dumped with special optionEdit
External resourcesEdit
By default CRIU allows to dump the set of processes and their resources if this set has no connections outside. However, in some situations it makes sense to ignore this external connection on dump and recreate one on restore. So, what this "connection outside" is? For example:
Main article: External resources
File locksEdit
A file lock is an object, that belongs to some filesystem. On dump it's impossible to find out whether this lock help by one task can be used by some other. Thus, CRIU doesn't dump tasks with held locks. The --file-locks CLI option tells CRIU to dump the lock.
Main article: File locks
Invisible filesEdit
Sometimes a file name cannot be found in a filesystem. In this case criu can leave a temporary name for it.
Main article: Invisible files
Cannot be dumped (yet)Edit
DevicesEdit
If a task has opened or mapped any character or block device, this typically means, it wants some connection to the hardware. In this case dump (and restore) is impossible. The exception is virtual devices like null, zero, etc. and TUN network device (used by OpenVPN).
The explanation why device file cannot be dumped and restored in a generic way is two fold. First of all, application can be dumped for live migration and on restore there can be no such device. But that's easy. Other than this, we don't know how all the devices work. App might have loaded some state into it, and in order to dump it properly we need to fetch that state. This is not something that can be done in a generic manner.
Open files from unmounted filesystemEdit
When a busy filesystem is "lazy" unmounted any references to it are cleaned up as soon as the filesystem is not busy anymore. If a process has an open file from a lazy-umounted filesystem, CRIU just can't checkpoint/restore this process, unless the file is closed.
See also: Dumping files
Tasks with debugger attachedEdit
CRIU uses the same API as debuggers do to get some tasks' state and this API (the ptrace one) doesn't allow for multiple debuggers to explore a task. Thus tasks under gdb or strace cannot be dumped.
Task from a different user (for non-root)Edit
For security reasons, if CRIU is requested by non-root to dump some other task, it doesn't do it unless the dumpee belongs to the same user.
See also: User-mode
Sockets other than TCP, UDP, UNIX, packet and netlinkEdit
Packetized pipesEdit
These are pipes created with O_DIRECT
Cork-ed UDP socketsEdit
Files sent over unix socketsEdit
SysVIPC memory segment w/o IPC namespaceEdit
IPC objects are not tied to any tasks. Thus once CRIU meets an IPC memory attached to a task, it requires the whole IPC namespace to be dumped as well.
Dump/restore of graphical applicationsEdit
Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.