What's bad with V1 images

2013-12-20T19:37:39Z

Shawn Landden:

Current [[images]] format is great, but sometimes we find problems with it. This page collects all we don't like about them and would like to change some time in the future (once we change this, image format version will be changed as well).

* vma.proto vma_entry->fd is unused
* ipc-msg.proto ipc_msg/ipc_msg_entry names mess
* sk-packet.proto vs packet-sock.proto names mess (all sockets .proto files are sk-<something>)
* core.proto blk_sigset for master thread is on task_core_entry, but should be in respective thread_core_entry
* pstree.proto: sid and pgid should NOT be there, but in core image
* core.proto -- padding for fpu is not used
* what to do with absent image files? Backward compatibility requires we still restore, common sense -- abort. Flooding inventory with every single new image doesn't sound that great.
* core.proto -- unused (though optional) ids field
* clear_thread_info in per-arch members
* it would be great to unify inotify and fanotify images into one fsnotify file
* currently we write checkpoint files with '''*.img''' extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to '''*.criu'''
* mnt_entry::fstype (in mnt.proto) should have enum fstype type
* all IDs in image should be in uint64 format (not uint32, like in reg_file_entry), this allows us to use unified ID generator over all images
* IPC mqueue sysctls are required, while in kernel they can be missing
* In proto files for registers (and more) it's better to use fixed- types, rather than plain
* use fixed32 and fixed64 where approiate instead of uint32 and uint64 https://developers.google.com/protocol-buffers/docs/proto

[[Category:Development]]

RPC

2013-12-14T00:13:06Z

Shawn Landden: /* Run */ systemd

CRIU-RPC is a remote procedure call (RPC) protocol which uses Google Protocol Buffers to encode its calls. The requests are served by CRIU service launched with <code>criu service</code> command. It uses a SEQPACKET Unix domain socket listening at <code>/var/run/criu-service.socket</code> as a transport.

== Protobuf messages ==
criu_req/criu_resp -- wrappers for requests/responses. They are to be used for transferring messages and needed to provide compatibility with an older versions of rpc. Field type in them _must_ be set accordingly to type of request/response that is stored. Types of request/response are defined in enum criu_req_type.

=== Request ===
==== criu_req ====
<pre>
message criu_req {
required criu_req_type type = 1;

optional criu_opts opts = 2;
}
</pre>

==== criu_req_type ====
There are only 2 request/response types for now.
<pre>enum criu_req_type {
EMPTY = 0;
DUMP = 1;
RESTORE = 2;
}
</pre>

==== criu_opts ====
It is used to store options.
<pre>message criu_opts {
required int32 images_dir_fd = 1;
optional int32 pid = 2;

optional bool leave_running = 3;
optional bool ext_unix_sk = 4;
optional bool tcp_established = 5;
optional bool evasive_devices = 6;
optional bool shell_job = 7;
optional bool file_locks = 8;
optional int32 log_level = 9 [default = 2];
optional string log_file = 10;
}</pre>

If no pid is set and type is DUMP, CRIU will dump client process by default.
Note: Whole tree <pid> must have the same uid, as a client, or client's uid must be == 0, otherwise CRIU won't dump nothing at all.

Only images_dir_fd is required, all other fields may not be set.
Client must open directory for/with images by himself and set images_dir_fd to it's fd.
CRIU will open /proc/<client's_pid>/fd/<images_dir_fd>, so it will work, if client is in another namespace.

The logic of setting request is the same as when setting options in console. Here is an example:
<pre>#criu restore -D /path/to/imgs_dir -v4 -o restore.log</pre>
is equal to:
<pre>
request.type = RESTORE;

request.opts.imgs_dir_fd = open("/path/to/imgs_dir")
request.opts.log_level = 4
request.opts.log_file = "restore.log"
</pre>

=== Response ===
==== criu_resp ====
<pre>message criu_resp {
required criu_req_type type = 1;
required bool success = 2;

optional criu_dump_resp dump = 3;
optional criu_restore_resp restore = 4;
}
</pre>
Field "success" reports result of processing request, while criu_***_resp store some request-specific information. The response type is set to the corresponding request type or to <code>EMPTY</code> to report a "generic" error.
==== criu_dump_resp ====
criu_dump_resp is used to store dump response from CRIU.
<pre>
message criu_dump_resp {
optional bool restored = 1;
}
</pre>

Field "restored" is set to "true" if process was restored.

==== criu_restore_resp ====
<pre>
message criu_restore_resp {
required int32 pid = 1;
}
</pre>
Field "pid" is set to the PID of the restored process.

== Run ==
=== Server ===
On a server side, CRIU creates SOCK_SEQPACKET Unix socket and listens for connections on it. After receiving criu_req, CRIU processes it, do what is requested and sends criu_resp with set request-specific criu_***_resp field back.
If CRIU gets unknown type of request, it will return criu_resp with type == EMPTY and success == false.

To launch service server, run:

<pre>#criu service [options]</pre>

Options accepted by service are

; --address <path>
: is where to put listening socket

; --pid-file <path>
: is where to write pid of service process

; --daemon
: tells service to daemonize

; -o <file>
: says where to write logs

; -v[N]
: sets the log-level

====systemd====
If you are running systemd you can just:
;systemctl start criu.socket

to get /var/run/criu-service.socket, and
;systemctl enable criu.socket

to make /var/run/criu-service.socket available at boot
=== Client ===
Client, in its turn, must connect to service socket, send criu_req with request in it, and wait for a criu_resp with response.
You can find examples of client programs in C and Python in test/rpc/.

With RPC facilities one can perform a [[self dump]].

== Security ==

See [[Usage#Security]].

CRIU - User contributions [en]

What's bad with V1 images

RPC