What cannot be checkpointed

Revision as of 19:21, 26 November 2013 by Xemul (talk | contribs) (Created page with "CRIU cannot dump ''all'' the possible states applications can live in. This article summarizes our experience in that area. == External resources == By default CRIU allows t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

CRIU cannot dump all the possible states applications can live in. This article summarizes our experience in that area.

External resources

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:

UNIX socket
Application may have a UNIX socket connected to some other app and the latter one is not dumped. This is called external UNIX socket.
TTY, group and session
If you start a program from shell, the tty, process group and session of the new program can be shared with the shell itself. People often meet this when they try CRIU for the first tome on a simple loop.
TCP connection
This socket is literally an external connection, so CRIU should be explicitly allowed to dump one.

File locks

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.

Devices

If an 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).