Linux processes are not things-in-themselves. They tend to cooperate with other parts of the system very actively. When CRIU tries to dump a process, that has such an external connection -- it refuses to make the dump. The reason is simple -- without knowing the details of such connections it's impossible to correctly detach the process from its peer on dump and attach back on restore.
Though sometimes we can handle this (this is what --shell-job, --ext-unix-sk and --tcp-established options are about), in many cases we cannot provide generic solution.
So, in order to address this problem we make CRIU pluggable. //by xemul@
A CRIU plugin is shared library, which is loaded before dumping or restoring. The CRIU tool looks up callback by their names. A library may provide any set of callbacks.
Each library can have cr_plugin_init() and cr_plugin_fini() functions for initializing and finalizing. cr_plugin_init() can return a negative value in an error case.
CRIU saves [images] in google protocol buffer format (PB format). We recomend to use this format for plugin images too.
All images are saved in a specified directory and plugins can call criu_get_image_dir() to get the file descriptor on this directory. The file descriptor is used, because the directory can be unreachable by path. For example if processes are restored in a new mount namespace.
When CRIU receives an unsupported object, it enumerates callbacks until one of them doesn't return something other than -ENOSUPP. Usually callbacks returns negative code in an error case. The -ENOSUPP code is a special one. It is returned, if a callback is not suitable for the object.
Each callback gets an unique identificator for each serialized object.
External unix sockets
int cr_plugin_dump_unix_sk(int sk, int id)
int cr_plugin_restore_unix_sk(int id)
External files are files, which are dumped and restored with help plugins.
int cr_plugin_dump_file(int fd, int id)
int cr_plugin_restore_file(int id)