Difference between revisions of "Installation"

Latest revision as of 01:56, 30 September 2023

criu is an utility to checkpoint/restore a process tree. This page describes how to get CRIU binary on your box.

Installing from packages[edit]

Many distributions provide ready-to-use packages. If no, or the CRIU version you want is not yet there, you will need to get CRIU sources and compile it.

Obtaining CRIU sources[edit]

You can download the source code as a release tarball or sync the git repository. If you plan to modify CRIU sources (e.g. to contribute the code back) the latter way is highly recommended. The latest and greatest sources are:

Tarball:	criu-4.0.tar.gz
Version:	4.0 "CRIUDA"
Released:	20 Sep 2024
GIT tag:	v4.0

Installing build dependencies[edit]

Compiler and C Library[edit]

CRIU is mostly written in C and the build system is based on Makefiles. Thus just install standard gcc and make packages (on Debian use build-essential).

For building with 32bit tasks C/R support you will need libc6-dev-i386, gcc-multilib instead of gcc.

Cross-compilation for ARM is also possible.

Protocol Buffers[edit]

CRIU uses the Google Protocol Buffers to read and write images. The protoc tool is used at build time and CRIU is linked with the libprotobuf-c.so. Also CRIT uses python bindings and the descriptor.proto file which typically provided by a distribution's protobuf development package.

RPM packages: protobuf protobuf-c protobuf-c-devel protobuf-compiler protobuf-devel protobuf-python

Deb packages: libprotobuf-dev libprotobuf-c-dev protobuf-c-compiler protobuf-compiler python3-protobuf

Optionally, you may build protobuf from sources.

Other stuff[edit]

pkg-config to check on build library dependencies.
python-ipaddress is used by CRIT to pretty-print IP addresses and is also required by zdtm.py
libbsd-devel (RPM) / libbsd-dev (DEB) If available, CRIU will be compiled with setproctitle() support and set verbose process titles on service workers.
iproute2 version 3.5.0 or higher is needed for dumping network namespaces. The latest one can be cloned from iproute2. It should be compiled and a path to ip set as the CR_IP_TOOL variable
nftables (RPM) / libnftables-dev (DEB) If available, CRIU will be compiled with nftables C/R support
libcap-devel (RPM) / libcap-dev (DEB) - Require
libnet-devel libnl3-devel (RPM) / libnet1-dev (DEB) / libnl-3-dev libnet-dev (Ubuntu) - Require
libaio-devel (RPM) / libaio-dev (DEB) is needed to run tests
gnutls-devel (RPM) / libgnutls28-dev (DEB), if available, CRIU will be compiled with TLS support
python2-future or python3-future is now needed for zdtm.py tests launcher
libdrm-devel (RPM) / libdrm-dev (DEB) If available, CRIU will be compiled with support for AMD GPUs.

For APT use the --no-install-recommends parameter is to avoid asciidoc pulling in a lot of dependencies. Also read about ZDTM test suite if you will run CRIU tests, those sources need other deps.

Building the tool[edit]

Simply run make in the CRIU source directory. This is the standard way, but there are some options available.

There's a docker-build target in Makefile which builds CRIU in Ubuntu Docker container. Just run make docker-build and that's it.
CRIU has functionality that is either optional or behaves differently depending on the kernel CRIU is running on. By default build process includes maximum of it, but this behavior can be changed.
You may specify build dependencies by hands

Installing[edit]

CRIU works perfectly even when run from the sources directory (with the ./criu/criu command), but if you want to have in standard paths run make install. You may need to install asciidoc and xmlto packages to make install-man work.

Checking That It Works[edit]

Linux kernel v3.11 or newer is required, with some specific config options turned on. Various advanced CRIU features might require even newer kernel. So the first thing to do is to check the kernel by running criu check. At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing. If your distribution does not provide needed kernel, you might want to compile one yourself.

You can then try running the ZDTM Test Suite which sits in the test/zdtm/ directory.

@@ Line 1: / Line 1: @@
-== What CRtools is ==
+<code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to get CRIU binary on your box.
-'''CRtools''' is an utility to checkpoint/restore process tree. Unlike checkpoint/restore implemented completely in kernel space,
+== Installing from packages ==
-it tries to achieve the same target operating in user space. Since the tools and overall concept are still under heavy development
-stage there are some known limitations applied
-# Only pure x86-64 environment is supported, no IA32 emulation allowed.
+Many distributions provide ready-to-use [[packages]]. If no, or the CRIU version you want is not yet there, you will need to get CRIU sources and compile it.
-# There is no way to use cgroups freezer facility yet.
-# No network or IPC checkpoint/restore supported.
-== Basic design ==
+== Obtaining CRIU sources ==
-=== Checkpoint ===
+You can download the source code as a [https://download.openvz.org/criu/ release tarball] or sync the [https://github.com/checkpoint-restore/criu git repository]. If you plan to modify CRIU sources (e.g. to [[How to submit patches|contribute the code back]]) the latter way is highly recommended. The latest and greatest sources are: {{Latest release}}
-The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools takes all the information it needs).
+== Installing build dependencies ==
-Which includes
-* Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''').
+=== Compiler and C Library ===
-* Pipes parameters.
-* Memory maps (via '''/proc/$pid/maps''').
-The process dumper (lets call it a dumper further) does the following steps during checkpoint stage
+CRIU is mostly written in C and the build system is based on Makefiles. Thus just install standard <code>gcc</code> and <code>make</code> packages (on Debian use <code>[https://packages.debian.org/build-essential build-essential]</code>).
-# A '''$pid''' of a process group leader is obtained from the command line.
+For building with [[32bit tasks C/R]] support you will need <code>libc6-dev-i386, gcc-multilib</code> instead of <code>gcc</code>.
-# By using this '''$pid''' the dumper walks though '''/proc/$pid/status''' and gathers children '''$pids''' recursively. At the end we will have a process tree.
-# Then it takes every '''$pid''' from a process tree, sends ''SIGSTOP'' to every process found, and performs the following steps on each '''$pid'''.
-#* Collects VMA areas by parsing '''/proc/$pid/maps'''.
-#* Seizes a task via relatively new ptrace interface. Seizing a task means to put it into a special state when the task have no idea if it's being operated by ptrace.
-#* Core parameters of a task (such as registers and friends) are being dumped via ptrace interface and parsing '''/proc/$pid/stat''' entry.
-#* The dumper injects a parasite code into a task via ptrace interface. This allows us to dump pages of a task right from within the task's address space.
-#** An injection procedure is pretty simple - the dumper scans executable VMA areas of a task (which were collected previously) and tests if there a place for <code>syscall</code> call, then (by ptrace as well) it substitutes an original code with <code>syscall</code> instructions and creates a new VMA area inside process address space.
-#** Finally parasite code get copied into the new VMA and the former code which was modified during parasite bootstrap procedure get restored.
-#* Then (by using a parasite code) the dumper flushes contents of a task's pages to the file. And pulls out parasite code block completely, since we don't need it anymore.
-#* Once parasite removed a task get unseized via ptrace call but it remains stopped still.
-#* The dumper writes out files and pipes parameter and data.
-# The procedure continues for every '''$pid'''.
-=== Restore ===
+[[ARM crosscompile|Cross-compilation for ARM]] is also possible.
-The restore procedure (aka restorer) proceed in the following steps
+=== Protocol Buffers ===
-# A process tree has been read from a file.
+CRIU uses the [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] to read and write [[images]]. The <code>protoc</code> tool is used at build time and CRIU is linked with the <code>libprotobuf-c.so</code>. Also [[CRIT]] uses python  bindings and the <code>descriptor.proto</code> file which typically provided by a distribution's protobuf development package.
-# Every process started with saved (i.e. original) '''$pid''' via <code>clone()</code> call.
-# Files and pipes are restored (by restored it's meant - they are opened and positioned).
-# A new memory map is created, filled with data the program had at checkpoint time.
-# Finally the program is kicked to start with rt_sigreturn system call.
-<!--
+; RPM packages
-=== Kernel requirements ===
+: <code>protobuf protobuf-c protobuf-c-devel protobuf-compiler protobuf-devel protobuf-python </code>
-Since checkpoint and restore processes require some help from the Linux kernel, the following kernel patches are needed
+; Deb packages
+: <code>libprotobuf-dev libprotobuf-c-dev protobuf-c-compiler protobuf-compiler python3-protobuf</code>
-* procfs-report-eisdir-when-reading-sysctl-dirs-in-proc.patch
+Optionally, you may [[build protobuf]] from sources.
-* proc-fix-races-against-execve-of-proc-pid-fd.patch
-* proc-fix-races-against-execve-of-proc-pid-fd-fix.patch
-* proc-force-dcache-drop-on-unauthorized-access.patch
-* cr-statfs-callback-for-pipefs
-These patches are already in -mm tree and rather a preparation patches for the next series.
+=== Other stuff ===
-* fs-proc-switch-to-dentry
+* <code>pkg-config</code> to check on build library dependencies.
-* cr-proc-map-files-21
+* <code>python-ipaddress</code> is used by CRIT to pretty-print IP addresses and is also required by zdtm.py
+* <code>libbsd-devel</code> (RPM) / <code>libbsd-dev</code> (DEB) If available, CRIU will be compiled  with <code>setproctitle()</code> support and set verbose process titles on service workers.
+* <code>iproute2</code> version 3.5.0 or higher is needed for dumping network namespaces. The latest one can be cloned from [http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=summary iproute2]. It should be compiled and a path to ip set as the [[environment variables|<code>CR_IP_TOOL</code> variable]]
+* <code>nftables</code> (RPM) / <code>libnftables-dev</code> (DEB) If available, CRIU will be compiled with nftables C/R support
+* <code>libcap-devel</code> (RPM) / <code>libcap-dev</code> (DEB) - Require
+* <code>libnet-devel libnl3-devel</code> (RPM) / <code>libnet1-dev</code> (DEB) / <code>libnl-3-dev libnet-dev</code> (Ubuntu) - Require
+* <code>libaio-devel</code> (RPM) / <code>libaio-dev</code> (DEB) is needed to run tests
+* <code>gnutls-devel</code> (RPM) / <code>libgnutls28-dev</code> (DEB), if available, CRIU will be compiled with [[TLS]] support
+* <code>python2-future</code> or <code>python3-future</code> is now needed for zdtm.py tests launcher
+* <code>libdrm-devel</code> (RPM) / <code>libdrm-dev</code> (DEB) If available, CRIU will be compiled with support for AMD GPUs.
-These patches introduce '''/proc/$pid/msp_files'''.
+For APT use the <code>--no-install-recommends</code> parameter is to avoid asciidoc pulling in a lot of dependencies.
+Also read about [[ZDTM test suite]] if you will run CRIU tests, those sources need other deps.
-* cr-clone-with-pid-support
+== Building the tool ==
-This one introduce ability to clone process with specified pid.
+Simply run <code>make</code> in the CRIU source directory. This is the standard way, but there are some options available.
-* cr-proc-add-children
+# There's a ''docker-build'' target in Makefile which builds CRIU in Ubuntu Docker container. Just run <code>make docker-build</code> and that's it.
+# CRIU has functionality that is either optional or behaves differently depending on the kernel CRIU is running on. By default build process includes maximum of it, but this behavior [[configuring|can be changed]].
+# You may [[Manual build deps|specify build dependencies by hands]]
-This one introduce "Children" line to '''/proc/$pid/status'''.
+== Installing ==
-* fs-add-do-close
+CRIU works perfectly even when run from the sources directory (with the <code>./criu/criu</code> command), but if you want to have in standard paths run <code>make install</code>. You may need to install <code>asciidoc</code> and <code>xmlto</code> packages to make install-man work.
-* fs-proc-add-tls
-* fs-proc-add-mm-task-stat
-These ones provides missing pieces of process' information which is needed for checkpoint/restore.
+== Checking That It Works ==
-* binfmt-elf-for-cr-5
+Linux kernel v3.11 or newer is required, with some specific config options turned on. Various advanced CRIU features might require even newer kernel.  So the first thing to do is to [[Checking the kernel|check the kernel]] by running <code>criu check</code>. At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing. If your distribution does not provide needed kernel, you might want to [[Linux kernel|compile one yourself]].
-This one provides new Elf file format.
+You can then try running the [[ZDTM Test Suite]] which sits in the <code>test/zdtm/</code> directory.
--->
-== Download crtools ==
+== Further reading ==
-The '''crtools''' utility itself is hosted at [https://github.com/cyrillos/crtools github].
+* [[Usage]]
-Clone this repo to test new functionality.
+* [[Advanced usage]]
+* [[:Category:HOWTO]]
-Also '''crtools''' requires some additional patches to be applied on the linux kernel (on top of v3.2-rc6 to be precise).
+[[Category:HOWTO]]
+[[Category:Editor help needed]]
-So clone [https://github.com/cyrillos/linux-2.6 linux-2.6-crtools.git], checkout ''crtools'' branch
-and compile the kernel.
-== Configure the linux kernel ==
-Make sure you have the following options turned on
-# General setup -> Checkpoint/restore support
-# Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface
-# Processor type and features -> Enable generic object ID infrastructure
-Note you might have to enable
-* General setup -> Configure standard kernel features
-option, which depends on
-* General setup -> Embedded system
-(welcome to Kconfig reverse chains hell).