https://criu.org/api.php?action=feedcontributions&user=Cov&feedformat=atomCRIU - User contributions [en]2024-03-28T23:05:20ZUser contributionsMediaWiki 1.35.6https://criu.org/index.php?title=Installation&diff=2942Installation2016-06-21T13:39:14Z<p>Cov: /* Dependencies */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
== Installing from packages ==<br />
<br />
Some 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.<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [https://github.com/xemul/criu git repository]. If you plan to modify CRIU sources the latter way is highly recommended.<br />
<br />
=== Getting source tarball ===<br />
: {{Latest release}}<br />
<br />
=== Cloning git repository ===<br />
git clone https://github.com/xemul/criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
<br />
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, <code>[https://packages.debian.org/build-essential build-essential]</code> will pull in both at once).<br />
<br />
For building on x86 you will need <code>libc6-dev-i386</code> and <code>gcc-multilib</code> instead of <code>gcc</code> which isn't compiled with i386 support.<br />
<br />
If you are cross compiling for ARM, use distribution packages or download prebuilt toolchains from Linaro.<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Downloading Linaro toolchains<br />
<div class="mw-collapsible-content"><br />
sudo apt-get install lib32stdc++6 lib32z1 # These are ia32 binaries<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
cd ..<br />
</div><br />
</div><br />
<br />
=== Protocol Buffers ===<br />
<br />
CRIU uses the [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] to read and write [[images]] and thus requires [https://github.com/protobuf-c/protobuf-c C language bindings]. The <code>protoc</code> tool is required at build time and the <code>libprotobuf-c.so</code> shared object is required at build and run time. [[CRIT]] also uses python language bindings for protocol buffers and requires the <code>descriptor.proto</code> file typically provided by a distribution's protobuf development package.<br />
<br />
==== Distribution Packages ====<br />
The easiest way is to install distribution packages.<br />
<br />
* RPM package names<br />
** <code>group Development\ Tools</code><br />
** <code>glibc-devel.i686 #on x86_64</code><br />
** <code>protobuf</code><br />
** <code>protobuf-c</code><br />
** <code>protobuf-c-devel</code><br />
** <code>protobuf-compiler</code><br />
** <code>protobuf-devel</code><br />
** <code>protobuf-python</code><br />
* Debian package names<br />
** <code>build-essential</code><br />
** <code>libprotobuf-dev</code><br />
** <code>libprotobuf-c0-dev</code><br />
** <code>protobuf-c-compiler</code><br />
** <code>protobuf-compiler</code><br />
** <code>python-protobuf</code><br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install <code>autoconf curl g++ libtool</code> packages first.<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To build protobuf<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To build protobuf-c<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To cross-compile for ARM some more tricks will be required.<br />
<div class="mw-collapsible-content"><br />
For ARMv7<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf \<br />
--disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
For ARM8<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu \<br />
--disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
</div><br />
</div><br />
<br />
=== Other deps ===<br />
* <code>pkg-config</code> to check on build library dependencies.<br />
* <code>libnl3</code> and <code>libnl3-devel</code> (RPM distros) or <code>libnl-3-dev</code> (DEB distros) for network operations.<br />
* <code>glibc-devel.i686</code> (RPM) or <code>libc6-dev-i386</code> (DEB) for building on x86-64<br />
* <code>python-ipaddr</code> is used by CRIT to pretty-print ip.<br />
* If <code>libbsd</code> available, CRIU will be compiled with setproctitle() support. It will allow to make process titles of service workers to be more verbose.<br />
* The iproute2 tool 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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
* <code>libcap-devel</code> (RPM) or <code>libcap-dev</code> (DEB)<br />
* If you would like to use <code>make test</code> you should install <code>libaio-devel</code><br />
* For test launcher <code>zdtm.py</code> you need <code>python2-yaml</code>.<br />
<br />
== Linux Kernel ==<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself.<br />
<br />
=== Configuring the kernel ===<br />
<br />
Most likely the first thing to enable is the <code>CONFIG_EXPERT=y</code> (General setup -> Configure standard kernel features (expert users)) option, which on x86_64 depends on the <code>CONFIG_EMBEDDED=y</code> (General setup -> Embedded system) one (welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
* ''General setup'' options<br />
** <code>CONFIG_CHECKPOINT_RESTORE=y</code> (Checkpoint/restore support)<br />
** <code>CONFIG_NAMESPACES=y</code> (Namespaces support)<br />
** <code>CONFIG_UTS_NS=y</code> (Namespaces support -> UTS namespace)<br />
** <code>CONFIG_IPC_NS=y</code> (Namespaces support -> IPC namespace)<br />
** <code>CONFIG_PID_NS=y</code> (Namespaces support -> PID namespaces)<br />
** <code>CONFIG_NET_NS=y</code> (Namespaces support -> Network namespace)<br />
** <code>CONFIG_FHANDLE=y</code> (Open by fhandle syscalls)<br />
** <code>CONFIG_EVENTFD=y</code> (Enable eventfd() system call)<br />
** <code>CONFIG_EPOLL=y</code> (Enable eventpoll support)<br />
* ''Networking support -> Networking options'' options for sock-diag subsystem<br />
** <code>CONFIG_UNIX_DIAG=y</code> (Unix domain sockets -> UNIX: socket monitoring interface)<br />
** <code>CONFIG_INET_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface)<br />
** <code>CONFIG_INET_UDP_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface)<br />
** <code>CONFIG_PACKET_DIAG=y</code> (Packet socket -> Packet: sockets monitoring interface)<br />
** <code>CONFIG_NETLINK_DIAG=y</code> (Netlink socket -> Netlink: sockets monitoring interface)<br />
* Other options<br />
** <code>CONFIG_INOTIFY_USER=y</code> (File systems -> Inotify support for userspace)<br />
** <code>CONFIG_IA32_EMULATION=y</code> (x86 only) (Executable file formats -> Emulations -> IA32 Emulation)<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable the <code>CONFIG_MEM_SOFT_DIRTY=y</code> (optional) (Processor type and features -> Track memory changes).<br />
<br />
Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
Simply run <code>make</code> in the CRIU source directory.<br />
<br />
=== Compilation in Docker container ===<br />
<br />
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.<br />
<br />
=== Non-standard compilation ===<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Building natively, but specifying built dependencies manually<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`<br />
cd criu-`uname -m`<br />
make \<br />
USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Cross Compilation for ARM<br />
<div class="mw-collapsible-content"><br />
ARMv7<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-arm<br />
cd criu-arm<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
ARMv8<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-aarch64<br />
cd criu-aarch64<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
</div><br />
</div><br />
<br />
== Installation ==<br />
CRIU works perfectly even when run from the sources directory (with the "./criu" command), but if you want to have in standard paths run <code>make install</code>.<br />
<br />
You may need to install the following packages to generate docs in Debian-based OS's to avoid errors from install-man:<br />
* <code>asciidoc</code><br />
* <code>xmlto</code><br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run <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. <br />
<br />
Some kernel functionality is required in rare cases and may not block the dump (but sometimes may). These features can be checked by adding the <code>--extra</code> flag.<br />
<br />
If you're using our custom kernel, then the <code>--all</code> option can be used, in this case CRIU would check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
== Further reading ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].<br />
<br />
[[Category:HOWTO]]</div>Covhttps://criu.org/index.php?title=Todo&diff=2593Todo2015-09-08T15:35:41Z<p>Cov: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! component<br />
! task<br />
! complexity<br />
! potential/willing assignee<br />
! comments<br />
|-<br />
| crtools/crit || Library/API to access pagemap+page images || medium || - || The [[memory dumps]] are quite sophisticated. It would be nice to have a library or API to access the data in them using some simple API. IOW -- API-ize the page_read.c<br />
|-<br />
| crtools || Zombies with threads :) || easy || - || When milti-thread task's leader thread exits task turns into zombie state, but the other threads keep running. Need to support this (zdt test pthread02).<br />
|-<br />
| tests || automate process of measurement code coverage || easy || - || It is required to automate process of getting code coverage. We have code coverage results [http://criu.org/cov/ measured in 2012]. Would be nice to get up to date results on periodic basis and without manual actions.<br />
|-<br />
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.<br />
|-<br />
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.<br />
|-<br />
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.<br />
|-<br />
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.<br />
|-<br />
| crtools || Implement [[restorer v2]] || hard (v2) || - ||<br />
|-<br />
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]] <br />
|-<br />
| crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public.<br />
|-<br />
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].<br />
|-<br />
| crtools || Support chroot-ed mount namespace || medium || - || If the root task lives in another mount namespace ''and'' has its root moved (with chroot()) CRIU dump fails with errors about inability to resolve files' paths. This is because CRIU treats the mount namespace's root as the init task's root which should be "/".<br />
|-<br />
| crtools || Non-stop memory (first?) pre-dump || medium || - || When reading only the memory we can avoid freezing tasks and draining memory with parasite. There's a system call named "read_process_vm" which can help us accessing the other task's memory. The disadvantage of this approach is the need for additional memory. We may control this behaviour by reading memory in chunks and not allocating to much of additional buffers.<br />
|-<br />
| kernel/crtools || Speed up fetching info about tasks || medium || Andrey Vagin || Using proc to get info about tasks is nice but too slow. We have measured that having socket-based engine that would fetch info about tasks from the kernel speeds things up significantly. So Andrey is working on the [[Task-diag]] patchset that would implement that.<br />
|-<br />
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.<br />
|-<br />
| crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem.<br />
|-<br />
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.<br />
|-<br />
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.<br />
|-<br />
| crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user.<br />
|-<br />
| crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form.<br />
|-<br />
| crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks.<br />
|-<br />
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.<br />
|-<br />
| crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.<br />
|-<br />
| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.<br />
|-<br />
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].<br />
|-<br />
| crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore.<br />
|-<br />
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.<br />
|-<br />
| crtools || Lazy restore using [[userfaultfd]] || medium || xemul || It might make sense to restore tasks w/o putting all the memory into respective places. Instead, the VMAs in question can be marked as "lazy" and pages will get filled into them in the background and, upon demand, in the out-of-order manner. The functionality is related to lazy migration and seamless kernel update tasks.<br />
|-<br />
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.<br />
|-<br />
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.<br />
|-<br />
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.<br />
|-<br />
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.<br />
|-<br />
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.<br />
|-<br />
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.<br />
|-<br />
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.<br />
|-<br />
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?<br />
|-<br />
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.<br />
|-<br />
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.<br />
|-<br />
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.<br />
|-<br />
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.<br />
|-<br />
| crtools || [[Applying images]] || hard (v2) || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.<br />
|-<br />
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.<br />
|-<br />
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.<br />
|-<br />
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is [[invisible files|not alive]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.<br />
|-<br />
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.<br />
|-<br />
| kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.<br />
|-<br />
| crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored.<br />
|-<br />
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.<br />
|-<br />
| crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts.<br />
|-<br />
| crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions.<br />
|-<br />
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.<br />
|-<br />
| crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing.<br />
|-<br />
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).<br />
|-<br />
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.<br />
|-<br />
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.<br />
|-<br />
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.<br />
|-<br />
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.<br />
|-<br />
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.<br />
|-<br />
| kernel || Fix VDSO remapping on non-x86 architectures || medium || Laurent Dufour, cov || However some architectures like PowerPC and ARM are keeping a reference to the VDSO base address to build the signal return stack frame by calling the VDSO sigreturn service. So once the VDSO has been moved, this reference is no more valid and the signal frame built later are not usable.<br />
|-<br />
| tests || Run many/all tests in "container" || medium || - || Currently we run zdtm tests one-by-one. It would be nice to run the all in one pseudo-container and C/R them as one big subtree.<br />
|-<br />
| tests || Trinity-like (fuzz) testing || hard || - || The existing suite is 99% functionality testing. Need more sophisticated testing -- take a process that has done a random set of actions, C/R one, check that all is OK. The latter is the most complicated thing.<br />
|-<br />
| tests || Split mountpoints.c test into pieces || easy || - || Currently this one is one big set of tests. Need more fine-grained set.<br />
|-<br />
| tests/infrastructure || Run tests on patches sent to the mailing lists || medium || Ruslan Kuprieiev || It's quite typical that a set sent to the mailing list fails some tests. Need a robot that would monitor the list, check the patches and send the result back.<br />
|-<br />
| tests || Fault injection || hard || - || Need some way to test error paths in CRIU. Right now we rely on the developers to write correct code :\ This is the most critical on dump.<br />
|-<br />
| crtools || Zombies with threads || medium || - || Support processes with alive threads and a dead leader<br />
|-<br />
| crtools || Unix sender address || medium || - || Restore sender addresses for unix socket messages<br />
|-<br />
| crtools || --leave-stopped for restore || easy || - || Restore task but leave it stopped<br />
|}<br />
<br />
[[Category:Development]]<br />
[[Category:Plans]]</div>Covhttps://criu.org/index.php?title=Comparison_to_other_CR_projects&diff=2534Comparison to other CR projects2015-07-23T12:13:52Z<p>Cov: /* (In-Kernel) Linux Checkpoint/Restart */</p>
<hr />
<div>This pages tries to explain differences between CRIU and other C/R solutions.<br />
<br />
== DMTCP ==<br />
<br />
{{:DMTCP}}<br />
<br />
== BLCR ==<br />
<br />
Berkeley Lab Checkpoint/Restart (BLCR) is a part of the Scalable Systems Software Suite , <br />
developed by the Future Technologies Group at Lawrence Berkeley National Lab under SciDAC <br />
funding from the United States Department of Energy. It is an Open Source, system-level <br />
checkpointer designed with High Performance Computing (HPC) applications in mind: in particular <br />
CPU and memory intensive batch-scheduled MPI jobs. BLCR is implemented as a GPL-licensed <br />
loadable kernel module for Linux 2.4.x and 2.6.x kernels on the x86, x86_64, PPC/PPC64, ARM architectures, and a <br />
small LGPL-licensed library.<br />
<br />
== PinLIT / PinPlay ==<br />
<br />
PinLIT (Pin-Long Instruction Trace) is a checkpointing tool built on top of Intel's proprietary [https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool PIN binary instrumentation tool] described on page 48 of [https://cseweb.ucsd.edu/~calder/papers/thesis-cristiano.pdf Cristiano Pereira's PhD thesis]. It records the processor's (big) architectural register state and all pages of memory that contain application and shared library code, optimizing size by only storing memory used during a desired interval.<br />
<br />
[https://software.intel.com/en-us/articles/program-recordreplay-toolkit PinPlay] or the Program Record/Replay Toolkit appears to be the successor of or new name for PinLIT. <br />
<br />
Both tools appear primarily focused on reducing benchmark runtime on slow computer architecture simulators, leveraging sampling algorithms such as SimPoint.<br />
<br />
== (In-Kernel) Linux Checkpoint/Restart ==<br />
<br />
(In-kernel) [https://ckpt.wiki.kernel.org/index.php/Main_Page Linux Checkpoint/Restart] was a project from around 2008 to around 2010 to implement checkpoint/restart of Linux processes.<br />
<br />
== CRIU, DMTCP, BLCR, OpenVZ comparison table ==<br />
<br />
“looks\seems like yes/no” - i found only unproved message(s) saying “yes”/“no”<br />
<br />
“not yet” - it is officially planned or i found no reasons, why it can’t be done.<br />
<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
!<br />
! CRIU<br />
! DMTCP<br />
! BLCR<br />
! OpenVZ<br />
<br />
|-<br />
| Arch<br />
| x86_64, ARM<br />
| x86, x86_64, ARM<br />
| x86, x86_64, PPC/PPC64, ARM<br />
| x86, x86_64<br />
<br />
|-<br />
| OS<br />
| Linux<br />
| Linux<br />
| Linux<br />
| Linux<br />
<br />
|-<br />
| Uses standard kernel?<br />
| {{Yes}}, provided it's 3.11 or later<br />
| {{Yes}}<br />
| {{Yes}}, just needs to load module<br />
| {{No}}. OpenVZ kernel is required<br />
<br />
|-<br />
| Can be used without preloading special libraries before app start?<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Can be used as non-root user?<br />
| {{Yes}}, but user can only manipulate tasks belonging to him<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
<br />
|-<br />
| Can run unmodified programs?<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}. Statically linked and/or threaded apps are unsupported.<br />
| {{Yes}}<br />
<br />
|-<br />
| Can run unprepared tasks?<br />
| {{Yes}}<br />
| {{No}}. It preloads the DMTCP library. That library runs before the routine main(). It creates a second thread. The checkpoint thread then creates a socket to the DMTCP coordinator and registers itself. The checkpoint thread also creates a signal handler.<br />
| {{No}}. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly.<br />
| {{Yes}}<br />
<br />
|-<br />
| Retains behavior of the c/r-ed programs?<br />
| {{Yes}} (but see [[What can change after C/R]])<br />
| {{No}}, because of wrappers on system calls<br />
| {{No}}, because of wrappers on system calls<br />
| {{Yes}}<br />
<br />
|-<br />
| Live migration<br />
| {{Yes}}, even if kernel, libs, etc are newer. Can use [[memory changes tracking]] to decrease freeze time<br />
| {{Yes}}, if both kernels are recent<br />
| {{Yes}}, but if all components are the same. Even if prelinked addresses are different, it will not restore, but it can save the whole used libs and localization files to restore program on the different machine<br />
| {{Yes}}<br />
<br />
|-<br />
| Containers<br />
| {{Yes}}, LXC and OpenVZ containers<br />
| {{No}}. It doesn't support namespaces, so it probably can’t dump containers <br />
| {{No|Looks like no}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Parallel/distributed computations libraries<br />
| {{No}} (planned)<br />
| {{Yes}}. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress<br />
| {{Yes}}. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT<br />
| {{Yes}}<br />
<br />
|-<br />
| Possible to C/R of gdb with debugged app?<br />
| {{No}}, because they are using the same interface<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| X Window apps (KDE, GNOME, etc)<br />
| {{Yes}}, via VNC<br />
| {{Yes}}, via VNC<br />
| {{No|Looks like no}}<br />
| {{Yes}}, via VNC<br />
<br />
<br />
|-<br />
| Solutions for invocation in the custom software<br />
| {{Yes}}, [[RPC]] and [[C API]]<br />
| {{Yes}}, plugins and API<br />
| {{No|Not yet}}<br />
| {{Yes}}, via ioctl calls<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
|-<br />
| Unix sockets<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| UDP sockets<br />
| {{Yes}}, both ipv4 and ipv6<br />
| {{No|Not yet}}. Developers of dmtcp had no request for this<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| TCP sockets<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Established TCP connection<br />
| {{Yes}}<br />
| {{No}}, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Infiniband<br />
| {{No}}<br />
| {{No|Not yet, developing is on the half-way}}<br />
| {{No}}<br />
| {{No}}<br />
<br />
|-<br />
| Multithread support<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Multiprocess<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Process groups and sessions<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Zombies<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Namespaces<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Ptraced programs<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| System V IPC<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Memory mappings<br />
| {{Yes}}, all kinds<br />
| {{Yes}}<br />
| {{Partial}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Pipes<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Terminals<br />
| {{Yes}}, but only Unix98 PTYs<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Non-POSIX files (inotify, signalfd, eventfd, etc)<br />
| {{Yes}}, inotify, fanotify, epoll, signalfd, eventfd<br />
| {{Yes}}, epoll, eventfd, signalfd are already supported and inotify will be supported in future<br />
| {{No|Looks like no}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Timers<br />
| {{Yes}}<br />
| {{No}}. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process.<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Shared resources (files, mm, etc.)<br />
| {{Yes}}. SysVIPC, files, fd table and memory<br />
| {{Yes}}. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors<br />
| {{No}}, but it is planned to support shared mmap regions<br />
| {{Yes}}<br />
<br />
|-<br />
| Block devices<br />
| {{No}}<br />
| {{Yes|Looks like yes}}<br />
| {{No}}<br />
| {{No}}<br />
<br />
<br />
|-<br />
| Character devices<br />
| {{Yes}}, only /dev/null, /dev/zero, etc. are supported<br />
| {{Yes}}, looks like null and zero are supported<br />
| {{Yes}}, /dev/null and /dev/zero<br />
| {{Yes}}<br />
<br />
|-<br />
| Capture the contents of open files<br />
| {{Yes}}, if file is unlinked<br />
| {{No|Looks like no}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|}<br />
<br />
== Sources ==<br />
DMTCP:<br />
*http://dmtcp.sourceforge.net/<br />
*http://dmtcp.sourceforge.net/papers/dmtcp.pdf<br />
*http://www.ccs.neu.edu/home/gene/papers/ccgrid06.pdf<br />
*http://research.cs.wisc.edu/htcondor/CondorWeek2010/condor-presentations/cooperman-dmtcp.pdf<br />
*http://dmtcp.sourceforge.net/papers/mtcp.pdf<br />
<br />
BLCR:<br />
*https://upc-bugs.lbl.gov/blcr/doc/html/<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-49659.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/blcr.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/checkpointSurvey-020724b.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/lacsi-2003.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-60520.pdf<br />
<br />
== External links ==<br />
<br />
* [http://dmtcp.sourceforge.net/FAQ.html#Internals How does DMTCP work?]<br />
<br />
[[Category:Under the hood]]</div>Covhttps://criu.org/index.php?title=Comparison_to_other_CR_projects&diff=2533Comparison to other CR projects2015-07-23T12:13:25Z<p>Cov: </p>
<hr />
<div>This pages tries to explain differences between CRIU and other C/R solutions.<br />
<br />
== DMTCP ==<br />
<br />
{{:DMTCP}}<br />
<br />
== BLCR ==<br />
<br />
Berkeley Lab Checkpoint/Restart (BLCR) is a part of the Scalable Systems Software Suite , <br />
developed by the Future Technologies Group at Lawrence Berkeley National Lab under SciDAC <br />
funding from the United States Department of Energy. It is an Open Source, system-level <br />
checkpointer designed with High Performance Computing (HPC) applications in mind: in particular <br />
CPU and memory intensive batch-scheduled MPI jobs. BLCR is implemented as a GPL-licensed <br />
loadable kernel module for Linux 2.4.x and 2.6.x kernels on the x86, x86_64, PPC/PPC64, ARM architectures, and a <br />
small LGPL-licensed library.<br />
<br />
== PinLIT / PinPlay ==<br />
<br />
PinLIT (Pin-Long Instruction Trace) is a checkpointing tool built on top of Intel's proprietary [https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool PIN binary instrumentation tool] described on page 48 of [https://cseweb.ucsd.edu/~calder/papers/thesis-cristiano.pdf Cristiano Pereira's PhD thesis]. It records the processor's (big) architectural register state and all pages of memory that contain application and shared library code, optimizing size by only storing memory used during a desired interval.<br />
<br />
[https://software.intel.com/en-us/articles/program-recordreplay-toolkit PinPlay] or the Program Record/Replay Toolkit appears to be the successor of or new name for PinLIT. <br />
<br />
Both tools appear primarily focused on reducing benchmark runtime on slow computer architecture simulators, leveraging sampling algorithms such as SimPoint.<br />
<br />
== (In-Kernel) Linux Checkpoint/Restart ==<br />
<br />
(In-kernel) [https://ckpt.wiki.kernel.org/index.php/Main_Page Linux Checkpoint/Restart] was a project from around 2008 to around 2010 to implemented checkpoint/restart of Linux processes.<br />
<br />
== CRIU, DMTCP, BLCR, OpenVZ comparison table ==<br />
<br />
“looks\seems like yes/no” - i found only unproved message(s) saying “yes”/“no”<br />
<br />
“not yet” - it is officially planned or i found no reasons, why it can’t be done.<br />
<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
!<br />
! CRIU<br />
! DMTCP<br />
! BLCR<br />
! OpenVZ<br />
<br />
|-<br />
| Arch<br />
| x86_64, ARM<br />
| x86, x86_64, ARM<br />
| x86, x86_64, PPC/PPC64, ARM<br />
| x86, x86_64<br />
<br />
|-<br />
| OS<br />
| Linux<br />
| Linux<br />
| Linux<br />
| Linux<br />
<br />
|-<br />
| Uses standard kernel?<br />
| {{Yes}}, provided it's 3.11 or later<br />
| {{Yes}}<br />
| {{Yes}}, just needs to load module<br />
| {{No}}. OpenVZ kernel is required<br />
<br />
|-<br />
| Can be used without preloading special libraries before app start?<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Can be used as non-root user?<br />
| {{Yes}}, but user can only manipulate tasks belonging to him<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
<br />
|-<br />
| Can run unmodified programs?<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}. Statically linked and/or threaded apps are unsupported.<br />
| {{Yes}}<br />
<br />
|-<br />
| Can run unprepared tasks?<br />
| {{Yes}}<br />
| {{No}}. It preloads the DMTCP library. That library runs before the routine main(). It creates a second thread. The checkpoint thread then creates a socket to the DMTCP coordinator and registers itself. The checkpoint thread also creates a signal handler.<br />
| {{No}}. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly.<br />
| {{Yes}}<br />
<br />
|-<br />
| Retains behavior of the c/r-ed programs?<br />
| {{Yes}} (but see [[What can change after C/R]])<br />
| {{No}}, because of wrappers on system calls<br />
| {{No}}, because of wrappers on system calls<br />
| {{Yes}}<br />
<br />
|-<br />
| Live migration<br />
| {{Yes}}, even if kernel, libs, etc are newer. Can use [[memory changes tracking]] to decrease freeze time<br />
| {{Yes}}, if both kernels are recent<br />
| {{Yes}}, but if all components are the same. Even if prelinked addresses are different, it will not restore, but it can save the whole used libs and localization files to restore program on the different machine<br />
| {{Yes}}<br />
<br />
|-<br />
| Containers<br />
| {{Yes}}, LXC and OpenVZ containers<br />
| {{No}}. It doesn't support namespaces, so it probably can’t dump containers <br />
| {{No|Looks like no}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Parallel/distributed computations libraries<br />
| {{No}} (planned)<br />
| {{Yes}}. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress<br />
| {{Yes}}. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT<br />
| {{Yes}}<br />
<br />
|-<br />
| Possible to C/R of gdb with debugged app?<br />
| {{No}}, because they are using the same interface<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| X Window apps (KDE, GNOME, etc)<br />
| {{Yes}}, via VNC<br />
| {{Yes}}, via VNC<br />
| {{No|Looks like no}}<br />
| {{Yes}}, via VNC<br />
<br />
<br />
|-<br />
| Solutions for invocation in the custom software<br />
| {{Yes}}, [[RPC]] and [[C API]]<br />
| {{Yes}}, plugins and API<br />
| {{No|Not yet}}<br />
| {{Yes}}, via ioctl calls<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
|-<br />
| Unix sockets<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| UDP sockets<br />
| {{Yes}}, both ipv4 and ipv6<br />
| {{No|Not yet}}. Developers of dmtcp had no request for this<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| TCP sockets<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Established TCP connection<br />
| {{Yes}}<br />
| {{No}}, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Infiniband<br />
| {{No}}<br />
| {{No|Not yet, developing is on the half-way}}<br />
| {{No}}<br />
| {{No}}<br />
<br />
|-<br />
| Multithread support<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Multiprocess<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Process groups and sessions<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Zombies<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Namespaces<br />
| {{Yes}}<br />
| {{No}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Ptraced programs<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| System V IPC<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Memory mappings<br />
| {{Yes}}, all kinds<br />
| {{Yes}}<br />
| {{Partial}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Pipes<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Terminals<br />
| {{Yes}}, but only Unix98 PTYs<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Non-POSIX files (inotify, signalfd, eventfd, etc)<br />
| {{Yes}}, inotify, fanotify, epoll, signalfd, eventfd<br />
| {{Yes}}, epoll, eventfd, signalfd are already supported and inotify will be supported in future<br />
| {{No|Looks like no}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Timers<br />
| {{Yes}}<br />
| {{No}}. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process.<br />
| {{Yes}}<br />
| {{Yes}}<br />
<br />
|-<br />
| Shared resources (files, mm, etc.)<br />
| {{Yes}}. SysVIPC, files, fd table and memory<br />
| {{Yes}}. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors<br />
| {{No}}, but it is planned to support shared mmap regions<br />
| {{Yes}}<br />
<br />
|-<br />
| Block devices<br />
| {{No}}<br />
| {{Yes|Looks like yes}}<br />
| {{No}}<br />
| {{No}}<br />
<br />
<br />
|-<br />
| Character devices<br />
| {{Yes}}, only /dev/null, /dev/zero, etc. are supported<br />
| {{Yes}}, looks like null and zero are supported<br />
| {{Yes}}, /dev/null and /dev/zero<br />
| {{Yes}}<br />
<br />
|-<br />
| Capture the contents of open files<br />
| {{Yes}}, if file is unlinked<br />
| {{No|Looks like no}}<br />
| {{No|Not yet}}<br />
| {{Yes}}<br />
<br />
|}<br />
<br />
== Sources ==<br />
DMTCP:<br />
*http://dmtcp.sourceforge.net/<br />
*http://dmtcp.sourceforge.net/papers/dmtcp.pdf<br />
*http://www.ccs.neu.edu/home/gene/papers/ccgrid06.pdf<br />
*http://research.cs.wisc.edu/htcondor/CondorWeek2010/condor-presentations/cooperman-dmtcp.pdf<br />
*http://dmtcp.sourceforge.net/papers/mtcp.pdf<br />
<br />
BLCR:<br />
*https://upc-bugs.lbl.gov/blcr/doc/html/<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-49659.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/blcr.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/checkpointSurvey-020724b.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/lacsi-2003.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-60520.pdf<br />
<br />
== External links ==<br />
<br />
* [http://dmtcp.sourceforge.net/FAQ.html#Internals How does DMTCP work?]<br />
<br />
[[Category:Under the hood]]</div>Covhttps://criu.org/index.php?title=Todo&diff=2400Todo2015-04-09T19:29:42Z<p>Cov: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! component<br />
! task<br />
! complexity<br />
! potential/willing assignee<br />
! comments<br />
|-<br />
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.<br />
|-<br />
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.<br />
|-<br />
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.<br />
|-<br />
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.<br />
|-<br />
| crtools || Implement [[restorer v2]] || hard (v2) || - ||<br />
|-<br />
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]] <br />
|-<br />
| crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public.<br />
|-<br />
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].<br />
|-<br />
| crtools || Support chroot-ed mount namespace || medium || - || If the root task lives in another mount namespace ''and'' has its root moved (with chroot()) CRIU dump fails with errors about inability to resolve files' paths. This is because CRIU treats the mount namespace's root as the init task's root which should be "/".<br />
|-<br />
| crtools || Non-stop memory (first?) pre-dump || medium || - || When reading only the memory we can avoid freezing tasks and draining memory with parasite. There's a system call named "read_process_vm" which can help us accessing the other task's memory. The disadvantage of this approach is the need for additional memory. We may control this behaviour by reading memory in chunks and not allocating to much of additional buffers.<br />
|-<br />
| kernel/crtools || Speed up fetching info about tasks || medium || Andrey Vagin || Using proc to get info about tasks is nice but too slow. We have measured that having socket-based engine that would fetch info about tasks from the kernel speeds things up significantly. So Andrey is working on the [[Task-diag]] patchset that would implement that.<br />
|-<br />
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.<br />
|-<br />
| crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem.<br />
|-<br />
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.<br />
|-<br />
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.<br />
|-<br />
| crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user.<br />
|-<br />
| crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form.<br />
|-<br />
| crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks.<br />
|-<br />
| kernel/crtools || Make proper "check lock present" API in the kernel || medium || - || Currently we detect where a file lock belongs to by locking the file again with the alternative lock type and check how kernel reacts on that. This is not nice as it may tune the lock state on a file. Instead we need the "check lock on fd" call in the kernel.<br />
|-<br />
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.<br />
|-<br />
| crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.<br />
|-<br />
| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.<br />
|-<br />
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].<br />
|-<br />
| crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore.<br />
|-<br />
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.<br />
|-<br />
| crtools || Lazy restore using [[userfaultfd]] || medium || xemul || It might make sense to restore tasks w/o putting all the memory into respective places. Instead, the VMAs in question can be marked as "lazy" and pages will get filled into them in the background and, upon demand, in the out-of-order manner. The functionality is related to lazy migration and seamless kernel update tasks.<br />
|-<br />
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.<br />
|-<br />
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.<br />
|-<br />
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.<br />
|-<br />
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.<br />
|-<br />
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.<br />
|-<br />
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.<br />
|-<br />
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.<br />
|-<br />
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?<br />
|-<br />
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.<br />
|-<br />
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.<br />
|-<br />
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those.<br />
|-<br />
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.<br />
|-<br />
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.<br />
|-<br />
| crtools || [[Applying images]] || hard (v2) || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.<br />
|-<br />
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.<br />
|-<br />
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.<br />
|-<br />
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is [[invisible files|not alive]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.<br />
|-<br />
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.<br />
|-<br />
| kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.<br />
|-<br />
| crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored.<br />
|-<br />
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.<br />
|-<br />
| crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts.<br />
|-<br />
| crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions.<br />
|-<br />
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.<br />
|-<br />
| crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing.<br />
|-<br />
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).<br />
|-<br />
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.<br />
|-<br />
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.<br />
|-<br />
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.<br />
|-<br />
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.<br />
|-<br />
| crtools || Remove hardcoded TASK_SIZE (at least for AArch32) || medium || cov || Dumping an AArch32 application using an AArch32 CRIU under an AArch64 kernel fails because TASK_SIZE is wrong. If TASK_SIZE were determined at runtime, the process would be able to proceed further. TASK_SIZE could be guessed using uname/cpuinfo and rules, probed with a series of accesses, or perhaps, following the example of PAGE_SIZE, the ELF auxiliary vector should include it.<br />
|-<br />
| crtools || Hardcoded PAGE_SIZE (at least for AArch64) || medium || cov || Dumping an AArch64 under an AArch64 kernel with 64K pages fails because PAGE_SIZE is wrong. Many uses of the PAGE_SIZE constant don't actually need an exact page size. Maybe split uses into PAGE_OR_LESS, EXEC_PAGESIZE (max possible for a platform), and page_size (actual value, probably pulled from auxv in memory or /proc or from smaps in /proc).<br />
|-<br />
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.<br />
|-<br />
| kernel || Fix VDSO remapping on non-x86 architectures || medium || Laurent Dufour, cov || However some architectures like PowerPC and ARM are keeping a reference to the VDSO base address to build the signal return stack frame by calling the VDSO sigreturn service. So once the VDSO has been moved, this reference is no more valid and the signal frame built later are not usable.<br />
|}<br />
<br />
[[Category:Development]]<br />
[[Category:Plans]]</div>Covhttps://criu.org/index.php?title=Todo&diff=2399Todo2015-04-09T19:21:31Z<p>Cov: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! component<br />
! task<br />
! complexity<br />
! potential/willing assignee<br />
! comments<br />
|-<br />
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.<br />
|-<br />
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.<br />
|-<br />
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.<br />
|-<br />
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.<br />
|-<br />
| crtools || Implement [[restorer v2]] || hard (v2) || - ||<br />
|-<br />
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]] <br />
|-<br />
| crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public.<br />
|-<br />
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].<br />
|-<br />
| crtools || Support chroot-ed mount namespace || medium || - || If the root task lives in another mount namespace ''and'' has its root moved (with chroot()) CRIU dump fails with errors about inability to resolve files' paths. This is because CRIU treats the mount namespace's root as the init task's root which should be "/".<br />
|-<br />
| crtools || Non-stop memory (first?) pre-dump || medium || - || When reading only the memory we can avoid freezing tasks and draining memory with parasite. There's a system call named "read_process_vm" which can help us accessing the other task's memory. The disadvantage of this approach is the need for additional memory. We may control this behaviour by reading memory in chunks and not allocating to much of additional buffers.<br />
|-<br />
| kernel/crtools || Speed up fetching info about tasks || medium || Andrey Vagin || Using proc to get info about tasks is nice but too slow. We have measured that having socket-based engine that would fetch info about tasks from the kernel speeds things up significantly. So Andrey is working on the [[Task-diag]] patchset that would implement that.<br />
|-<br />
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.<br />
|-<br />
| crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem.<br />
|-<br />
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.<br />
|-<br />
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.<br />
|-<br />
| crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user.<br />
|-<br />
| crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form.<br />
|-<br />
| crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks.<br />
|-<br />
| kernel/crtools || Make proper "check lock present" API in the kernel || medium || - || Currently we detect where a file lock belongs to by locking the file again with the alternative lock type and check how kernel reacts on that. This is not nice as it may tune the lock state on a file. Instead we need the "check lock on fd" call in the kernel.<br />
|-<br />
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.<br />
|-<br />
| crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.<br />
|-<br />
| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.<br />
|-<br />
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].<br />
|-<br />
| crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore.<br />
|-<br />
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.<br />
|-<br />
| crtools || Lazy restore using [[userfaultfd]] || medium || xemul || It might make sense to restore tasks w/o putting all the memory into respective places. Instead, the VMAs in question can be marked as "lazy" and pages will get filled into them in the background and, upon demand, in the out-of-order manner. The functionality is related to lazy migration and seamless kernel update tasks.<br />
|-<br />
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.<br />
|-<br />
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.<br />
|-<br />
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.<br />
|-<br />
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.<br />
|-<br />
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.<br />
|-<br />
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.<br />
|-<br />
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.<br />
|-<br />
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?<br />
|-<br />
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.<br />
|-<br />
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.<br />
|-<br />
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those.<br />
|-<br />
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.<br />
|-<br />
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.<br />
|-<br />
| crtools || [[Applying images]] || hard (v2) || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.<br />
|-<br />
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.<br />
|-<br />
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.<br />
|-<br />
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is [[invisible files|not alive]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.<br />
|-<br />
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.<br />
|-<br />
| kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.<br />
|-<br />
| crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored.<br />
|-<br />
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.<br />
|-<br />
| crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts.<br />
|-<br />
| crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions.<br />
|-<br />
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.<br />
|-<br />
| crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing.<br />
|-<br />
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).<br />
|-<br />
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.<br />
|-<br />
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.<br />
|-<br />
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.<br />
|-<br />
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.<br />
|-<br />
| crtools || Remove hardcoded TASK_SIZE (at least for AArch32) || medium || cov || Dumping an AArch32 application using an AArch32 CRIU under an AArch64 kernel fails because TASK_SIZE is wrong. If TASK_SIZE were determined at runtime, the process would be able to proceed further. TASK_SIZE could be guessed using uname/cpuinfo and rules, probed with a series of accesses, or perhaps, following the example of PAGE_SIZE, the ELF auxiliary vector should include it.<br />
|-<br />
| crtools || Hardcoded PAGE_SIZE (at least for AArch64) || medium || cov || Dumping an AArch64 under an AArch64 kernel with 64K pages fails because PAGE_SIZE is wrong. Many uses of the PAGE_SIZE constant don't actually need an exact page size. Maybe split uses into PAGE_OR_LESS, EXEC_PAGESIZE (max possible for a platform), and page_size (actual value, probably pulled from auxv in memory or /proc or from smaps in /proc).<br />
|-<br />
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.<br />
|}<br />
<br />
[[Category:Development]]<br />
[[Category:Plans]]</div>Covhttps://criu.org/index.php?title=Todo&diff=2398Todo2015-04-09T19:21:09Z<p>Cov: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! component<br />
! task<br />
! complexity<br />
! potential/willing assignee<br />
! comments<br />
|-<br />
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.<br />
|-<br />
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.<br />
|-<br />
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.<br />
|-<br />
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.<br />
|-<br />
| crtools || Implement [[restorer v2]] || hard (v2) || - ||<br />
|-<br />
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]] <br />
|-<br />
| crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public.<br />
|-<br />
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].<br />
|-<br />
| crtools || Support chroot-ed mount namespace || medium || - || If the root task lives in another mount namespace ''and'' has its root moved (with chroot()) CRIU dump fails with errors about inability to resolve files' paths. This is because CRIU treats the mount namespace's root as the init task's root which should be "/".<br />
|-<br />
| crtools || Non-stop memory (first?) pre-dump || medium || - || When reading only the memory we can avoid freezing tasks and draining memory with parasite. There's a system call named "read_process_vm" which can help us accessing the other task's memory. The disadvantage of this approach is the need for additional memory. We may control this behaviour by reading memory in chunks and not allocating to much of additional buffers.<br />
|-<br />
| kernel/crtools || Speed up fetching info about tasks || medium || Andrey Vagin || Using proc to get info about tasks is nice but too slow. We have measured that having socket-based engine that would fetch info about tasks from the kernel speeds things up significantly. So Andrey is working on the [[Task-diag]] patchset that would implement that.<br />
|-<br />
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.<br />
|-<br />
| crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem.<br />
|-<br />
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.<br />
|-<br />
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.<br />
|-<br />
| crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user.<br />
|-<br />
| crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form.<br />
|-<br />
| crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks.<br />
|-<br />
| kernel/crtools || Make proper "check lock present" API in the kernel || medium || - || Currently we detect where a file lock belongs to by locking the file again with the alternative lock type and check how kernel reacts on that. This is not nice as it may tune the lock state on a file. Instead we need the "check lock on fd" call in the kernel.<br />
|-<br />
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.<br />
|-<br />
| crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.<br />
|-<br />
| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.<br />
|-<br />
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].<br />
|-<br />
| crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore.<br />
|-<br />
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.<br />
|-<br />
| crtools || Lazy restore using [[userfaultfd]] || medium || xemul || It might make sense to restore tasks w/o putting all the memory into respective places. Instead, the VMAs in question can be marked as "lazy" and pages will get filled into them in the background and, upon demand, in the out-of-order manner. The functionality is related to lazy migration and seamless kernel update tasks.<br />
|-<br />
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.<br />
|-<br />
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.<br />
|-<br />
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.<br />
|-<br />
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.<br />
|-<br />
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.<br />
|-<br />
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.<br />
|-<br />
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.<br />
|-<br />
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?<br />
|-<br />
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.<br />
|-<br />
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.<br />
|-<br />
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those.<br />
|-<br />
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.<br />
|-<br />
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.<br />
|-<br />
| crtools || [[Applying images]] || hard (v2) || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.<br />
|-<br />
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.<br />
|-<br />
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.<br />
|-<br />
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is [[invisible files|not alive]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.<br />
|-<br />
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.<br />
|-<br />
| kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.<br />
|-<br />
| crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored.<br />
|-<br />
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.<br />
|-<br />
| crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts.<br />
|-<br />
| crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions.<br />
|-<br />
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.<br />
|-<br />
| crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing.<br />
|-<br />
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).<br />
|-<br />
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.<br />
|-<br />
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.<br />
|-<br />
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.<br />
|-<br />
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.<br />
|-<br />
| crtools || Remove hardcoded TASK_SIZE (at least for AArch32) || medium || cov || Dumping an AArch32 application using an AArch32 CRIU under an AArch64 kernel fails because TASK_SIZE is wrong. If TASK_SIZE were determined at runtime, the process would be able to proceed further. TASK_SIZE could be guessed using uname/cpuinfo and rules, probed with a series of accesses, or perhaps, following the example of PAGE_SIZE, the ELF auxiliary vector should include it.<br />
|-<br />
| crtools || Hardcoded PAGE_SIZE (at least for AArch64) || medium || cov || Dumping an AArch64 under an AArch64 kernel with 64K pages fails because PAGE_SIZE is wrong. Many uses of the PAGE_SIZE constant don't actually need an exact page size. Maybe split uses into PAGE_OR_LESS, EXEC_PAGESIZE (max possible for a platform), and page_size (actual value, probably pulled from auxv in memory or /proc or from smaps in /proc).<br />
|-<br />
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HERLPERS=n.<br />
|}<br />
<br />
[[Category:Development]]<br />
[[Category:Plans]]</div>Covhttps://criu.org/index.php?title=Todo&diff=2397Todo2015-04-09T19:06:55Z<p>Cov: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! component<br />
! task<br />
! complexity<br />
! potential/willing assignee<br />
! comments<br />
|-<br />
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.<br />
|-<br />
| kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel.<br />
|-<br />
| crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do.<br />
|-<br />
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.<br />
|-<br />
| crtools || Implement [[restorer v2]] || hard (v2) || - ||<br />
|-<br />
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]] <br />
|-<br />
| crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public.<br />
|-<br />
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].<br />
|-<br />
| crtools || Support chroot-ed mount namespace || medium || - || If the root task lives in another mount namespace ''and'' has its root moved (with chroot()) CRIU dump fails with errors about inability to resolve files' paths. This is because CRIU treats the mount namespace's root as the init task's root which should be "/".<br />
|-<br />
| crtools || Non-stop memory (first?) pre-dump || medium || - || When reading only the memory we can avoid freezing tasks and draining memory with parasite. There's a system call named "read_process_vm" which can help us accessing the other task's memory. The disadvantage of this approach is the need for additional memory. We may control this behaviour by reading memory in chunks and not allocating to much of additional buffers.<br />
|-<br />
| kernel/crtools || Speed up fetching info about tasks || medium || Andrey Vagin || Using proc to get info about tasks is nice but too slow. We have measured that having socket-based engine that would fetch info about tasks from the kernel speeds things up significantly. So Andrey is working on the [[Task-diag]] patchset that would implement that.<br />
|-<br />
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.<br />
|-<br />
| crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem.<br />
|-<br />
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.<br />
|-<br />
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.<br />
|-<br />
| crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user.<br />
|-<br />
| crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form.<br />
|-<br />
| crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks.<br />
|-<br />
| kernel/crtools || Make proper "check lock present" API in the kernel || medium || - || Currently we detect where a file lock belongs to by locking the file again with the alternative lock type and check how kernel reacts on that. This is not nice as it may tune the lock state on a file. Instead we need the "check lock on fd" call in the kernel.<br />
|-<br />
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.<br />
|-<br />
| crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.<br />
|-<br />
| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.<br />
|-<br />
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].<br />
|-<br />
| crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore.<br />
|-<br />
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.<br />
|-<br />
| crtools || Lazy restore using [[userfaultfd]] || medium || xemul || It might make sense to restore tasks w/o putting all the memory into respective places. Instead, the VMAs in question can be marked as "lazy" and pages will get filled into them in the background and, upon demand, in the out-of-order manner. The functionality is related to lazy migration and seamless kernel update tasks.<br />
|-<br />
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.<br />
|-<br />
| crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup.<br />
|-<br />
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.<br />
|-<br />
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.<br />
|-<br />
| crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that.<br />
|-<br />
| crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different.<br />
|-<br />
| crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably.<br />
|-<br />
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?<br />
|-<br />
| crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one.<br />
|-<br />
| crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too.<br />
|-<br />
| crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those.<br />
|-<br />
| crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon.<br />
|-<br />
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.<br />
|-<br />
| crtools || [[Applying images]] || hard (v2) || xemul@ w/ students || Think about ability to take images and apply them to a living task(s). Like it was described in the "rollback" feature above. Another exampl -- repopulate fdtable according to data from image. Yet another use-case -- when doing partial migration (see below) we'll need to modify one part to switch from pipes to sockets. What else? With constant replication of tree state we can do incremental dumps on source node and apply those increments on pre-created replicas on the destination node.<br />
|-<br />
| crtools || Partial migration || hard || - || If tasks subtree has connections to the rest of the tree (e.g. with pipes of unix sockets) we try to detect this and refuse the dump. It should be possible to take part of the tree, migrating it somewhere and recreating the mentioned links with some other appropriate IPC channel. E.g. pipes with sockets, shared memory with distributed shared memory and so on.<br />
|-<br />
| crtools || Shared objects (mm/fs) support || medium || - || Things created with CLONE_FOO flags are not supported now (exception -- full threads). Now we have the kcmp syscall and can do it. The shared fdtable (CLONE_FILES) is supported, the next candidate is mm sharing, as we do know, that MySQL does so sometimes.<br />
|-<br />
| crtools || Smart paths resolution || hard || - || Files can be overmounted. In this case CRIU will refuse the dump saying that file is [[invisible files|not alive]] but inaccessible by its name. Need a way to resolve paths to such. There are two ways: 1. Move mounts, that overlap the desired path temporarily, then open the file, then move the mountpoint back. 2. When creating a new mount pre-open an fd keeping the mountpoint. Later, do accurate path resolve and call openat() on proper mountpoint fd.<br />
|-<br />
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.<br />
|-<br />
| kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.<br />
|-<br />
| crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored.<br />
|-<br />
| crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored.<br />
|-<br />
| crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts.<br />
|-<br />
| crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions.<br />
|-<br />
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.<br />
|-<br />
| crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing.<br />
|-<br />
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).<br />
|-<br />
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.<br />
|-<br />
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.<br />
|-<br />
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.<br />
|-<br />
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.<br />
|-<br />
| crtools || Remove hardcoded TASK_SIZE (at least for AArch32) || medium || cov || Dumping an AArch32 application using an AArch32 CRIU under an AArch64 kernel fails because TASK_SIZE is wrong. If TASK_SIZE were determined at runtime, the process would be able to proceed further. TASK_SIZE could be guessed using uname/cpuinfo and rules, probed with a series of accesses, or perhaps, following the example of PAGE_SIZE, the ELF auxiliary vector should include it.<br />
|-<br />
| crtools || Hardcoded PAGE_SIZE (at least for AArch64) || medium || cov || Dumping an AArch64 under an AArch64 kernel with 64K pages fails because PAGE_SIZE is wrong. Many uses of the PAGE_SIZE constant don't actually need an exact page size. Maybe split uses into PAGE_OR_LESS, EXEC_PAGESIZE (max possible for a platform), and page_size (actual value, probably pulled from auxv in memory or /proc or from smaps in /proc).<br />
|}<br />
<br />
[[Category:Development]]<br />
[[Category:Plans]]</div>Covhttps://criu.org/index.php?title=Time_namespace&diff=2396Time namespace2015-04-09T19:05:30Z<p>Cov: </p>
<hr />
<div>Two things (for now) we want to solve with this:<br />
# Shift timer's offsets<br />
# Make start-time remain "unchanged" after C/R<br />
<br />
What about other kinds of counters like perf events and trace events?<br />
<br />
[[Category: Empty articles]]<br />
[[Category: Plans]]</div>Covhttps://criu.org/index.php?title=Installation&diff=2303Installation2015-03-26T18:56:30Z<p>Cov: /* Dependencies */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
== Installing from packages ==<br />
<br />
Some 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.<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository]. If you plan to modify CRIU sources the latter way is highly recommended.<br />
<br />
=== Getting source tarball ===<br />
{{Out|{{Latest release}}}}<br />
<br />
=== Cloning git repository ===<br />
git clone https://github.com/xemul/criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
<br />
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, <code>[https://packages.debian.org/build-essential build-essential]</code> will pull in both at once).<br />
<br />
If you are cross compiling for ARM, use distribution packages or download prebuilt toolchains from Linaro.<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Downloading Linaro toolchains<br />
<div class="mw-collapsible-content"><br />
sudo apt-get install lib32stdc++6 lib32z1 # These are ia32 binaries<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
cd ..<br />
</div><br />
</div><br />
<br />
=== Protocol Buffers ===<br />
<br />
CRIU uses the [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] to read and write [[images]] and thus requires [https://github.com/protobuf-c/protobuf-c C language bindings]. The <code>protoc</code> tool is required at build time and the <code>libprotobuf-c.so</code> shared object is required at build and run time. [[CRIT]] also uses python language bindings for protocol buffers and requires the <code>descriptor.proto</code> file typically provided by a distribution's protobuf development package.<br />
<br />
==== Distribution Packages ====<br />
The easiest way is to install distribution packages.<br />
<br />
* RPM package names<br />
** <code>protobuf</code><br />
** <code>protobuf-c</code><br />
** <code>protobuf-c-devel</code><br />
** <code>protobuf-compiler</code><br />
** <code>protobuf-devel</code><br />
** <code>protobuf-python</code><br />
* Debian package names<br />
** <code>libprotobuf-c0-dev</code><br />
** <code>protobuf-c-compiler</code><br />
** <code>protobuf-compiler</code><br />
** <code>protobuf-python</code><br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install <code>autoconf curl g++ libtool</code> packages first.<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To build protobuf<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To build protobuf-c<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
To cross-compile for ARM some more tricks will be required.<br />
<div class="mw-collapsible-content"><br />
For ARMv7<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf \<br />
--disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
For ARM8<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu \<br />
--disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
</div><br />
</div><br />
<br />
=== Other deps ===<br />
<br />
* <code>python-ipaddr</code> is used by CRIT to pretty-print ip.<br />
* If <code>libbsd</code> available, CRIU will be compiled with setproctitle() support. It will allow to make process titles of service workers to be more verbose.<br />
* The iproute2 tool 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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Linux Kernel ==<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself.<br />
<br />
=== Configuring the kernel ===<br />
<br />
Most likely the first thing to enable is the <code>CONFIG_EXPERT=y</code> (General setup -> Configure standard kernel features (expert users)) option, which on x86_64 depends on the <code>CONFIG_EMBEDDED=y</code> (General setup -> Embedded system) one (welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
* ''General setup'' options<br />
** <code>CONFIG_CHECKPOINT_RESTORE=y</code> (Checkpoint/restore support)<br />
** <code>CONFIG_NAMESPACES=y</code> (Namespaces support)<br />
** <code>CONFIG_UTS_NS=y</code> (Namespaces support -> UTS namespace)<br />
** <code>CONFIG_IPC_NS=y</code> (Namespaces support -> IPC namespace)<br />
** <code>CONFIG_PID_NS=y</code> (Namespaces support -> PID namespaces)<br />
** <code>CONFIG_NET_NS=y</code> (Namespaces support -> Network namespace)<br />
** <code>CONFIG_FHANDLE=y</code> (Open by fhandle syscalls)<br />
** <code>CONFIG_EVENTFD=y</code> (Enable eventfd() system call)<br />
** <code>CONFIG_EPOLL=y</code> (Enable eventpoll support)<br />
* ''Networking support -> Networking options'' options for sock-diag subsystem<br />
** <code>CONFIG_UNIX_DIAG=y</code> (Unix domain sockets -> UNIX: socket monitoring interface)<br />
** <code>CONFIG_INET_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface)<br />
** <code>CONFIG_INET_UDP_DIAG=y</code> (TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface)<br />
** <code>CONFIG_PACKET_DIAG=y</code> (Packet socket -> Packet: sockets monitoring interface)<br />
** <code>CONFIG_NETLINK_DIAG=y</code> (Netlink socket -> Netlink: sockets monitoring interface)<br />
* Other options<br />
** <code>CONFIG_INOTIFY_USER=y</code> (File systems -> Inotify support for userspace)<br />
** <code>CONFIG_IA32_EMULATION=y</code> (x86 only) (Executable file formats -> Emulations -> IA32 Emulation)<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable the <code>CONFIG_MEM_SOFT_DIRTY=y</code> (optional) (Processor type and features -> Track memory changes).<br />
<br />
Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
Simply run <code>make</code> in the CRIU source directory.<br />
<br />
=== Compilation in Docker container ===<br />
<br />
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.<br />
<br />
=== Non-standard compilation ===<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Building natively, but specifying built dependencies manually<br />
<div class="mw-collapsible-content"><br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`<br />
cd criu-`uname -m`<br />
make \<br />
USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check<br />
cd ../..<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
Cross Compilation for ARM<br />
<div class="mw-collapsible-content"><br />
ARMv7<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-arm<br />
cd criu-arm<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
ARMv8<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-aarch64<br />
cd criu-aarch64<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
</div><br />
</div><br />
<br />
== Installation ==<br />
CRIU works perfectly even when run from the sources directory (with the "./criu" command), but if you want to have in standard paths run <code>make install</code><br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run <code>criu check --ms</code>.<br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing. If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
== Further reading ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].<br />
<br />
[[Category:HOWTO]]</div>Covhttps://criu.org/index.php?title=Installation&diff=2187Installation2015-03-02T15:04:05Z<p>Cov: /* Linux Kernel */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
[[CRIT]] also uses python language bindings of Google Protocol Buffers and requires descriptor.proto from developer files that could be found in protobuf-devel package. <br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>, <code>protobuf-devel</code>, <code>protobuf-python</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>, <code>protobuf-compiler</code>, <code>protobuf-python</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
=== Other deps ===<br />
==== python-ipaddr ====<br />
Used in CRIT to pretty-print ip.<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`<br />
cd criu-`uname -m`<br />
make \<br />
USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-arm<br />
cd criu-arm<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-aarch64<br />
cd criu-aarch64<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT=y</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED=y</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE=y</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES=y</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS=y</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS=y</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS=y</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS=y</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE=y</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD=y</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL=y</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER=y</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION=y</code> (x86 only)<br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG=y</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG=y</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG=y</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG=y</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG=y</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY=y</code> (optional)<br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code># CONFIG_NET_PKTGEN is not set</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Installation ==<br />
<pre><br />
# make install<br />
</pre><br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].<br />
<br />
[[Category:HOWTO]]</div>Covhttps://criu.org/index.php?title=Articles&diff=2025Articles2015-02-05T19:25:13Z<p>Cov: </p>
<hr />
<div><noinclude>Articles about the CRIU project:</noinclude><br />
{|<br />
! Date !! Article<br />
|-<br />
| 2014-02-15 || [http://www.occamportal.org/images/reproduce/papers/reproduce14_paper_05.pdf Efficient, Accurate and Reproducible Simulation of Multi-Threaded Workloads] ([http://www.occamportal.org/images/reproduce/slides/reproduce14_slides_05.pdf slides]) at [http://www.occamportal.org/reproduce OCCAM REPRODUCE Workshop]<br />
|-<br />
| 2013-11-25 || [http://www.phoronix.com/scan.php?page=news_item&px=MTUyNjE v1.0 article] on Phoronix<br />
|-<br />
| 2013-11-25 || [http://lwn.net/Articles/574918/ A note about 1.0] on LWN<br />
|-<br />
| 2013-10-29 || Kernel summit [https://lwn.net/Articles/572125/ report] from LWN<br />
|-<br />
| 2013-02-01 || A blog [http://www.anchor.com.au/blog/2013/02/overview-of-checkpoint-and-restore-live-migrating-processes-on-a-linux-system/ post] upon LCA-2013 talk.<br />
|-<br />
| 2013-01-09 || LWN: [http://lwn.net/Articles/531939/ Checkpoint/restore and signals]<br />
|-<br />
| 2012-11-20 || LWN: [http://lwn.net/Articles/525675/ LCE: Checkpoint/restore in user space: are we there yet?]<br />
|-<br />
| 2012-05-01 || LWN: [http://lwn.net/Articles/495304/ TCP connection repair]<br />
|-<br />
| 2012-01-31 || LWN: [http://lwn.net/Articles/478111/ Preparing for user-space checkpoint/restore]<br />
|-<br />
| 2011-07-19 || LWN [http://lwn.net/Articles/452184/ Checkpoint/restart (mostly) in user space]<br />
|-<br />
| || Wikipedia: [http://en.wikipedia.org/wiki/CRIU en:CRIU], [http://ru.wikipedia.org/wiki/CRIU ru:CRIU]<br />
|-<br />
| ||OpenVZ blog: [http://openvz.livejournal.com/42414.html CRtools 0.1 released!] (+ LWN.net [http://lwn.net/Articles/507961/ repost], + [http://olemskoi.ru/node/8247 this repost])<br />
|-<br />
| || Debian includes [http://packages.qa.debian.org/c/crtools.html crtools package]<br />
|}<br />
<br />
{| class="mw-collapsible <includeonly>mw-collapsed</includeonly>" border="0"<br />
|-<br />
! style="text-align: left; font-weight: normal" | in Russian:<br />
|-<br />
| <br />
* [http://www.opennet.ru/opennews/art.shtml?num=38519 Анонс выхода 1.0] на opennet<br />
* [http://habrahabr.ru/post/177499/ В преддверии очередного релиза CRIU]<br />
* [http://www.it-computer.com/osvaivaem-sistemu-zamorozki-processov-criu Article] on it-computer<br />
* CRIU 0.2 release on [http://www.opennet.ru/opennews/art.shtml?num=34958 opennet]<br />
* CRIU: [http://events.yandex.ru/events/yac/2012/talks/352/ больше, чем живая миграция для Linux контейнеров]<br />
* Habr: [http://habrahabr.ru/post/148413/ CRIU — новый амбициозный проект для сохранения и восстановления состояния процессов]<br />
* Ru-OpenVZ blog: [http://ru-openvz.livejournal.com/5753.html Вышел первый релиз CRtools, версия 0.1]<br />
* opennet: [http://www.opennet.ru/opennews/art.shtml?num=34408 Первый релиз CRtools, утилиты для заморозки и восстановления состояния процессов в Linux]<br />
* LOR: [http://www.linux.org.ru/news/kernel/8021514 Вышел первый релиз CRtools, версия 0.1]<br />
* Копипаста о v0.1 "CRIU / CRtools 0.1 — создание контрольных точек Linux-приложений и восстановление с них": [http://rosinvest.com/novosti/949423 Rosinvest], [http://www.nixp.ru/news/11854.html NIXP] [http://pcnews.ru/top/news/day/criu-crtools-linux-openvz-checkpoint-restore-in-userspace-cpt-system-90-10-lxc-org-398305.html PCNews]<br />
|}</div>Covhttps://criu.org/index.php?title=Comparison_to_other_CR_projects&diff=2024Comparison to other CR projects2015-02-05T19:01:00Z<p>Cov: </p>
<hr />
<div>This pages tries to explain differences between CRIU and other C/R solutions.<br />
<br />
== [http://dmtcp.sourceforge.net DMTCP] ==<br />
<br />
{{:DMTCP}}<br />
<br />
== [https://ftg.lbl.gov/projects/CheckpointRestart BLCR] ==<br />
<br />
Berkeley Lab Checkpoint/Restart (BLCR) is a part of the Scalable Systems Software Suite , <br />
developed by the Future Technologies Group at Lawrence Berkeley National Lab under SciDAC <br />
funding from the United States Department of Energy. It is an Open Source, system-level <br />
checkpointer designed with High Performance Computing (HPC) applications in mind: in particular <br />
CPU and memory intensive batch-scheduled MPI jobs. BLCR is implemented as a GPL-licensed <br />
loadable kernel module for Linux 2.4.x and 2.6.x kernels on the x86, x86_64, PPC/PPC64, ARM architectures, and a <br />
small LGPL-licensed library.<br />
<br />
== PinLIT / PinPlay ==<br />
<br />
PinLIT (Pin-Long Instruction Trace) is a checkpointing tool built on top of Intel's proprietary [https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool PIN binary instrumentation tool] described on page 48 of [https://cseweb.ucsd.edu/~calder/papers/thesis-cristiano.pdf Cristiano Pereira's PhD thesis]. It records the processor's (big) architectural register state and all pages of memory that contain application and shared library code, optimizing size by only storing memory used during a desired interval.<br />
<br />
[https://software.intel.com/en-us/articles/program-recordreplay-toolkit PinPlay] or the Program Record/Replay Toolkit appears to be the successor of or new name for PinLIT. <br />
<br />
Both tools appear primarily focused on reducing benchmark runtime on slow computer architecture simulators, leveraging sampling algorithms such as SimPoint.<br />
<br />
== [http://criu.org CRIU], [http://dmtcp.sourceforge.net DMTCP], [https://ftg.lbl.gov/projects/CheckpointRestart BLCR], [https://openvz.org OpenVZ] ==<br />
<br />
“looks\seems like yes/no” - i found only unproved message(s) saying “yes”/“no”<br />
<br />
“not yet” - it is officially planned or i found no reasons, why it can’t be done.<br />
<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
!<br />
! CRIU<br />
! DMTCP<br />
! BLCR<br />
! OpenVZ<br />
<br />
|-<br />
| Arch<br />
| x86_64, ARM<br />
| x86, x86_64, ARM<br />
| x86, x86_64, PPC/PPC64, ARM<br />
| x86, x86_64<br />
<br />
|-<br />
| OS<br />
| Linux<br />
| Linux<br />
| Linux<br />
| Linux<br />
<br />
|-<br />
| Need in modified kernel<br />
| No, provided it's 3.11 and above<br />
| No<br />
| No, just need to load module. May be problems with installation on new kernels<br />
| Yes<br />
<br />
|-<br />
| App need to pre-load special libraries<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
<br />
|-<br />
| Requires root privileges<br />
| No, but user can only manipulate tasks belonging to him<br />
| No<br />
| No<br />
| Yes<br />
<br />
|-<br />
| Need to modify programs to C/R<br />
| No<br />
| No<br />
| Yes. There are some difficulties with statically linked applications, and with LinuxThreads (it does not support them at all)<br />
| No<br />
<br />
<br />
|-<br />
| Need to prepare tasks<br />
| No<br />
| Yes. It preloadsthe DMTCP library. That library runs before the routinemain(). It creates a second thread. Thecheckpoint thread then creates a socket to the DMTCP coordinator andregisters itself. The checkpoint thread also creates a signal handler.<br />
| Yes. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly.<br />
| No<br />
<br />
<br />
|-<br />
| Does it change behavior of the c/r-ed programs?<br />
| No<br />
| Yes, because of wrappers on system calls<br />
| Yes, because of wrappers on system calls<br />
| No<br />
<br />
|-<br />
| Live migration<br />
| Yes, even if kernel, libs, etc are newer. Can use Memory Changes Tracking to decrease freeze time<br />
| Yes, if both kernels are recent<br />
| Yes, but if all components are the same. Even if prelinked addresses are different,it will not restore, but it can save the whole used libs and localization files to restore program on the different machine<br />
| Yes<br />
<br />
|-<br />
| Containers<br />
| Yes, LXC and OpenVZ containers<br />
| No. It doesn't support namespaces, so it probably can’t dump containers <br />
| Looks like no<br />
| Yes<br />
<br />
|-<br />
| Parallel/distributed computations libraries<br />
| No (in plans)<br />
| Yes. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress<br />
| Yes. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT<br />
| Yes<br />
<br />
|-<br />
| C/R gdb with debugging app<br />
| No, because they are using the same interface<br />
| Yes<br />
| No<br />
| Yes<br />
<br />
|-<br />
| X-Windows apps (KDE, GNOME, etc)<br />
| Yes, by using vnc<br />
| Yes, by using vnc<br />
| Looks like no<br />
| Yes, by using vnc<br />
<br />
<br />
|-<br />
| Solutions for invocation in the custom software<br />
| Yes. [[RPC]] and [[C API]]<br />
| Yes. Plugins and API<br />
| Not yet<br />
| Yes. via ioctl calls<br />
<br />
|-<br />
| colspan="4" |<br />
<br />
|-<br />
| Unix sockets<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
<br />
|-<br />
| UDP sockets<br />
| Yes, both ipv4 and ipv6<br />
| Not yet. Developers of dmtcp had no request for this<br />
| Not yet<br />
| Yes<br />
<br />
|-<br />
| TCP sockets<br />
| Yes<br />
| Yes<br />
| Not yet<br />
| Yes<br />
<br />
|-<br />
| Established tcp connection<br />
| Yes<br />
| No, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart<br />
| No<br />
| Yes<br />
<br />
|-<br />
| Infiniband<br />
| No<br />
| Not yet, developing is on the half-way<br />
| No<br />
| No<br />
<br />
|-<br />
| Multithread support<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
<br />
|-<br />
| Multiprocess<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
<br />
|-<br />
| Process groups and sessions<br />
| Yes<br />
| Yes<br />
| Not yet<br />
| Yes<br />
<br />
|-<br />
| Zombies<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
<br />
|-<br />
| Namespaces<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
<br />
|-<br />
| Ptraced programs<br />
| No<br />
| Yes<br />
| No<br />
| Yes<br />
<br />
|-<br />
| System V IPC<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
<br />
|-<br />
| Memory mappings<br />
| Yes, all kinds<br />
| Yes<br />
| Yes, partially <br />
| Yes<br />
<br />
|-<br />
| Pipes<br />
| Yes<br />
| Yes<br />
| Not yet<br />
| Yes<br />
<br />
|-<br />
| Terminals<br />
| Yes, but only Unix98 PTYs<br />
| Yes<br />
| Yes<br />
| Yes<br />
<br />
|-<br />
| Non-posix files (inotify, signalfd, eventfd, etc)<br />
| Yes, inotify, fanotify, epoll, signalfd, eventfd<br />
| Yes, epoll, eventfd, signalfd are already supported and inotify will be supported in future<br />
| Looks like no<br />
| Yes<br />
<br />
|-<br />
| Timers<br />
| Yes<br />
| No. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process.<br />
| Yes<br />
| Yes<br />
<br />
|-<br />
| Shared resources (files, mm, etc.)<br />
| Yes. SysVIPC, files, fd table and memory<br />
| Yes. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors<br />
| No, but it is planned to suppord shared mmap regions<br />
| Yes<br />
<br />
|-<br />
| Block devices<br />
| No<br />
| Looks like yes<br />
| No<br />
| No<br />
<br />
<br />
|-<br />
| Character devices<br />
| Yes, only /dev/null, /dev/zero, etc. are supported<br />
| Yes, looks like null and zero are supported<br />
| Yes, /dev/null and /dev/zero<br />
| Yes<br />
<br />
|-<br />
| Capture the contents of open files<br />
| Yes, if file is unlinked<br />
| Looks like no<br />
| Not yet<br />
| Yes<br />
<br />
|}<br />
<br />
== Sources ==<br />
DMTCP:<br />
*http://dmtcp.sourceforge.net/<br />
*http://dmtcp.sourceforge.net/papers/dmtcp.pdf<br />
*http://www.ccs.neu.edu/home/gene/papers/ccgrid06.pdf<br />
*http://research.cs.wisc.edu/htcondor/CondorWeek2010/condor-presentations/cooperman-dmtcp.pdf<br />
*http://dmtcp.sourceforge.net/papers/mtcp.pdf<br />
<br />
BLCR:<br />
*https://upc-bugs.lbl.gov/blcr/doc/html/<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-49659.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/blcr.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/checkpointSurvey-020724b.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/lacsi-2003.pdf<br />
*https://ftg.lbl.gov/assets/projects/CheckpointRestart/Pubs/LBNL-60520.pdf<br />
<br />
== External links ==<br />
<br />
* [http://dmtcp.sourceforge.net/FAQ.html#Internals How does DMTCP work?]<br />
<br />
[[Category:Under the hood]]</div>Covhttps://criu.org/index.php?title=User_talk:Cov&diff=2023User talk:Cov2015-02-05T12:28:57Z<p>Cov: Created page with "== Staging 3rd generation multiple-architecture build and test instructions == mkdir matest git submodule add https://github.com/xemul/criu.git git submodule add https://g..."</p>
<hr />
<div>== Staging 3rd generation multiple-architecture build and test instructions ==<br />
<br />
mkdir matest<br />
git submodule add https://github.com/xemul/criu.git<br />
git submodule add https://github.com/google/protobut.git<br />
git submodule add https://github.com/protobuf-c/protobuf-c.git<br />
#qemu<br />
#linux<br />
#busybox<br />
#python?</div>Covhttps://criu.org/index.php?title=Installation&diff=1716Installation2014-10-10T16:52:54Z<p>Cov: /* Building CRIU From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`<br />
cd criu-`uname -m`<br />
make \<br />
USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-arm<br />
cd criu-arm<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-aarch64<br />
cd criu-aarch64<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/../`uname -m`-linux-gnu/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1715Installation2014-10-10T15:59:42Z<p>Cov: /* Building CRIU From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-`uname -m`<br />
cd criu-`uname -m`<br />
make \<br />
USERCFLAGS="-I`pwd`/../`uname -m`-linux-gnu/include -L`pwd`/../`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
sudo LD_LIBRARY_PATH=`pwd`/../`uname -m`-linux-gnu/lib ./criu check<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-arm<br />
cd criu-arm<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/../bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/../arm-linux-gnueabihf/include -L`pwd`/../arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
cd deps<br />
rsync -a --exclude=.git --exclude=deps .. criu-aarch64<br />
cd criu-aarch64<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/../bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/../aarch64-linux-gnu/include -L`pwd`/../aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
cd ../..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1714Installation2014-10-10T15:42:20Z<p>Cov: /* Cross Compiling for ARMv8 */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1713Installation2014-10-10T15:40:36Z<p>Cov: /* Cross Compiling for ARMv7 */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make install PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1712Installation2014-10-10T15:39:44Z<p>Cov: /* Cross Compiling for ARMv7 */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc PATH=`pwd`/../`uname -m`-linux-gnu/bin:$PATH<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1711Installation2014-10-10T15:38:17Z<p>Cov: /* Compiler and C Library */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> and <code>lib32z1</code> packages.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1710Installation2014-10-10T15:37:04Z<p>Cov: /* Compiler and C Library */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> package.<br />
<br />
mkdir -p deps/`uname -m`-linux-gnu<br />
cd deps<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz<br />
tar --strip=1 -C `uname -m`-linux-gnu -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1709Installation2014-10-10T15:18:48Z<p>Cov: /* Protocol Buffers with C Bindings */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> package.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [https://github.com/protobuf-c/protobuf-c C language bindings] of [https://developers.google.com/protocol-buffers/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git clone https://github.com/protobuf-c/protobuf-c.git protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1708Installation2014-10-10T15:02:17Z<p>Cov: /* Native protobuf */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> package.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git clone https://github.com/google/protobuf.git protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
=== Some minor, but useful dependencies ===<br />
==== libbsd ====<br />
If libbsd is available, CRIU will be compiled with setproctitle() support. It allows to make process titles of service workers to be more verbose.<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1671Installation2014-09-02T20:16:34Z<p>Cov: /* Compiler and C Library */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below. They are ia32 architecture binaries. On a modern Debian based x86_64 you will need to install the <code>lib32stdc++6</code> package.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1670Installation2014-09-02T19:43:29Z<p>Cov: /* Native protobuf-c */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
PKG_CONFIG_PATH=`pwd`/../`uname -m`-linux-gnu/lib/pkgconfig<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1669Installation2014-09-02T19:36:31Z<p>Cov: /* Native protobuf-c */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1668Installation2014-09-02T19:24:59Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl g++ libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1667Installation2014-09-02T19:22:07Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl libtool</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1666Installation2014-09-02T19:20:55Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code. On a Debian based system, you may have to install the following packages first: <code>autoconf curl</code>.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1627Installation2014-08-16T13:00:11Z<p>Cov: /* Native protobuf-c */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1585Installation2014-07-26T12:10:08Z<p>Cov: /* Building CRIU From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
make install<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
=== Native Compilation ===<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make \<br />
USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv7 ===<br />
<br />
make \<br />
ARCH=arm \<br />
CROSS_COMPILE=`pwd`/deps/bin/arm-linux-gnueabihf- \<br />
USERCFLAGS="-I`pwd`/deps/arm-linux-gnueabihf/include -L`pwd`/deps/arm-linux-gnueabihf/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Cross Compilation for ARMv8 ===<br />
<br />
make \<br />
ARCH=aarch64 \<br />
CROSS_COMPILE=`pwd`/deps/bin/aarch64-linux-gnu- \<br />
USERCFLAGS="-I`pwd`/deps/aarch64-linux-gnu/include -L`pwd`/deps/aarch64-linux-gnu/lib" \<br />
PATH="`pwd`/deps/`uname -m`-linux-gnu/bin:$PATH"<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1584Installation2014-07-26T11:22:24Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
===== Native protobuf =====<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Native protobuf-c =====<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
make install<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv7 =====<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
===== Cross Compiling for ARMv8 =====<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib"<br />
<br />
Here is an example of cross compiling for armv7.<br />
<br />
<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1583Installation2014-07-26T11:00:30Z<p>Cov: /* Distribution Packages */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-c-compiler</code>, <code>protobuf-c-devel</code>. Debian package names: <code>protobuf-c-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
make install<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib"<br />
<br />
Here is an example of cross compiling for armv7.<br />
<br />
<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1582Installation2014-07-26T10:56:44Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-compiler</code>,<code>protobuf-c-devel</code>. Debian package names: <code>protobuf-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu \<br />
CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include \<br />
LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib \<br />
PATH="`pwd`/../`uname -m`-linux-gnu/bin:$PATH"<br />
make<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
make install<br />
# Ignore test-full.proto: "foo.VALUE_B" uses the same enum value as "foo.VALUE_A" messages<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib"<br />
<br />
Here is an example of cross compiling for armv7.<br />
<br />
<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1581Installation2014-07-26T01:33:17Z<p>Cov: </p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Obtaining CRIU Source ==<br />
<br />
You can download the source code as a release tarball or sync the [http://git.criu.org/?p=criu.git;a=summary git repository].<br />
<br />
{{Out|{{Latest release}}}}<br />
<br />
git clone git://git.criu.org/criu.git<br />
cd criu<br />
<br />
== Dependencies ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir deps<br />
cd deps<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-compiler</code>,<code>protobuf-c-devel</code>. Debian package names: <code>protobuf-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`-linux-gnu<br />
make<br />
make install<br />
cd ../..<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./bootstrap.sh<br />
mkdir ../pbc-`uname -m`<br />
cd ../pbc-`uname -m`<br />
../protobuf-c/configure --prefix=`pwd`/../`uname -m`-linux-gnu CPPFLAGS=-I`pwd`/../`uname -m`-linux-gnu/include LDFLAGS=-L`pwd`/../`uname -m`-linux-gnu/lib<br />
make<br />
make install<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv7:<br />
<br />
cd deps<br />
mkdir -p pbc-arm<br />
cd pbc-arm<br />
../protobuf-c/configure --host=arm-linux-gnueabihf --prefix=`pwd`/../arm-linux-gnueabihf --disable-protoc CC=`pwd`/../bin/arm-linux-gnueabihf-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
If you would like to cross-compile for armv8:<br />
<br />
cd deps<br />
mkdir -p pbc-aarch64<br />
cd pbc-aarch64<br />
../protobuf-c/configure --host=aarch64-linux-gnu --prefix=`pwd`/../aarch64-linux-gnu --disable-protoc CC=`pwd`/../bin/aarch64-linux-gnu-gcc<br />
make<br />
make install<br />
cd ../..<br />
<br />
== Building CRIU From Source ==<br />
<br />
With the CRIU source obtained in the first step and dependencies satisfied in the second step, we are now compile CRIU. For native compilation with the dependencies met using distribution packages, simply run <code>make</code> in the CRIU source directory.<br />
<br />
Here is an example of building natively specifying manually built dependencies.<br />
<br />
make USERCFLAGS="-I`pwd`/deps/`uname -m`-linux-gnu/include -L`pwd`/deps/`uname -m`-linux-gnu/lib"<br />
<br />
Here is an example of cross compiling for armv7.<br />
<br />
<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1580Installation2014-07-26T00:41:14Z<p>Cov: /* Protocol Buffers with C Bindings */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir toolchains<br />
cd toolchains<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
export PATH="`pwd`/bin:$PATH"<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the [http://code.google.com/p/protobuf-c/ C language bindings] of [http://code.google.com/p/protobuf/ Google Protocol Buffers] for serialization. The <code>protoc</code> tool is required at build time and <code>libprotobuf-c.so</code> is required at build time and at run time, assuming dynamic linking.<br />
<br />
==== Distribution Packages ====<br />
The easiest approach for most would be to install distribution packages. RPM package names: <code>protobuf-compiler</code>,<code>protobuf-c-devel</code>. Debian package names: <code>protobuf-compiler</code>, <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source, you can use the following commands to obtain the source code repositories, configure, and build the code.<br />
<br />
mkdir deps<br />
cd deps<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/../`uname -m`<br />
make<br />
make install<br />
cd ../..<br />
<br />
cd deps<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh --prefix=`pwd`/../`uname -m` --disable-protoc<br />
make<br />
make install<br />
cd ..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1579Installation2014-07-25T23:41:38Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir toolchains<br />
cd toolchains<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
export PATH="`pwd`/bin:$PATH"<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
==== Distribution Packages ====<br />
CRIU uses the C bindings of Google's Protocol Buffers. The easiest approach for most would be to install a distribution packages. RPM package name: <code>protobuf-c-devel</code>. Debian package name: <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source instead of using a package, the Protocol Buffer library can be found at http://code.google.com/p/protobuf/, while the Protocol Buffer C bindings can be found at http://code.google.com/p/protobuf-c/. You can use the following commands to obtain the source code repositories via <code>git</code>. Note that when cross compiling you will need to compile once for your build machine in order to get a <code>protoc</code> binary to use in the build process, and build once for each target machine to generate <code>libprotobuf-c.so</code>.<br />
<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m`<br />
make<br />
make install<br />
cd ..<br />
<br />
If you are cross compiling, then you will additionally want to build a version for your target architecture. This example targets AArch64.<br />
<br />
cd protobuf<br />
./configure --host=aarch64-linux-gnu --prefix=`pwd`/aarch64 --with-protoc=`pwd`/`uname -m`/bin/protoc<br />
make<br />
make install<br />
cd ..<br />
<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m` PATH="`pwd`/../protobuf/`uname -m`/bin:$PATH"<br />
make<br />
make install<br />
cd ..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1578Installation2014-07-23T10:25:36Z<p>Cov: /* Prerequisites */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Compiler and C Library ===<br />
For native compilation on Debian based systems, install the <code>build-essential</code> package. For cross compiling for ARM and AArch64, the Linaro prebuilt toolchains are a good choice. Installing them is described below.<br />
<br />
mkdir toolchains<br />
cd toolchains<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.06_linux.tar.xz<br />
wget http://releases.linaro.org/14.06/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
tar --strip=1 -xf gcc-linaro-aarch64-linux-gnu-4.9-2014.06-02_linux.tar.xz<br />
export PATH="`pwd`/bin:$PATH"<br />
cd ..<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
==== Distribution Packages ====<br />
CRIU uses the C bindings of Google's Protocol Buffers. The easiest approach for most would be to install a distribution packages. RPM package name: <code>protobuf-c-devel</code>. Debian package name: <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source instead of using a package, the Protocol Buffer library can be found at http://code.google.com/p/protobuf/, while the Protocol Buffer C bindings can be found at http://code.google.com/p/protobuf-c/. You can use the following commands to obtain the source code repositories via <code>git</code>. Note that when cross compiling you will need to compile once for your build machine in order to get a <code>protoc</code> binary to use in the build process, and build once for each target machine to generate <code>libprotobuf.so</code>.<br />
<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m`<br />
make<br />
make install<br />
cd ..<br />
<br />
If you are cross compiling, then you will additionally want to build a version for your target architecture. This example targets AArch64.<br />
<br />
cd protobuf<br />
./configure --host=aarch64-linux-gnu --prefix=`pwd`/aarch64 --with-protoc=`pwd`/`uname -m`/bin/protoc<br />
make<br />
make install<br />
cd ..<br />
<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m` PATH="`pwd`/../protobuf/`uname -m`/bin:$PATH"<br />
make<br />
make install<br />
cd ..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1577Installation2014-07-23T10:08:17Z<p>Cov: /* Building Protocol Buffers From Source */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
==== Distribution Packages ====<br />
CRIU uses the C bindings of Google's Protocol Buffers. The easiest approach for most would be to install a distribution packages. RPM package name: <code>protobuf-c-devel</code>. Debian package name: <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source instead of using a package, the Protocol Buffer library can be found at http://code.google.com/p/protobuf/, while the Protocol Buffer C bindings can be found at http://code.google.com/p/protobuf-c/. You can use the following commands to obtain the source code repositories via <code>git</code>. Note that when cross compiling you will need to compile once for your build machine in order to get a <code>protoc</code> binary to use in the build process, and build once for each target machine to generate <code>libprotobuf.so</code>.<br />
<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
cd protobuf<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m`<br />
make<br />
make install<br />
cd ..<br />
<br />
If you are cross compiling, then you will additionally want to build a version for your target architecture. This example targets AArch64.<br />
<br />
cd protobuf<br />
./configure --host=aarch64-linux-gnu --prefix=`pwd`/aarch64 --with-protoc=`pwd`/`uname -m`/bin/protoc<br />
make<br />
make install<br />
cd ..<br />
<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
cd protobuf-c<br />
./autogen.sh<br />
./configure --prefix=`pwd`/`uname -m` PATH="`pwd`/../protobuf/`uname -m`/bin:$PATH"<br />
make<br />
make install<br />
cd ..<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1574Installation2014-07-23T00:20:46Z<p>Cov: /* Protocol Buffers with C Bindings */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
==== Distribution Packages ====<br />
CRIU uses the C bindings of Google's Protocol Buffers. The easiest approach for most would be to install a distribution packages. RPM package name: <code>protobuf-c-devel</code>. Debian package name: <code>libprotobuf-c0-dev</code>.<br />
<br />
==== Building Protocol Buffers From Source ====<br />
If you would like to build from source instead of using a package, the Protocol Buffer library can be found at http://code.google.com/p/protobuf/, while the Protocol Buffer C bindings can be found at http://code.google.com/p/protobuf-c/. You can use the following commands to obtain the source code repositories via <code>git</code>.<br />
<br />
git svn clone http://protobuf.googlecode.com/svn/trunk protobuf<br />
<br />
git svn clone http://protobuf-c.googlecode.com/svn/trunk protobuf-c<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1573Installation2014-07-22T10:06:19Z<p>Cov: </p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes how to manually build and install prerequisites and the tool itself.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Prerequisites ==<br />
<br />
=== Protocol Buffers with C Bindings ===<br />
<br />
CRIU uses the C bindings of Google's Protocol Buffers. The easiest approach for most would be to install a distribution packages. RPM package name: <code>protobuf-c-devel</code>. Debian package name: <code>libprotobuf-c0-dev</code>. If you would like to build from source, the Protocol Buffer library can be found at http://code.google.com/p/protobuf/, while the Protocol Buffer C bindings can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
=== Linux Kernel ===<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options must be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
At the moment it's known that CRIU will '''NOT''' work if packet generator module is loaded. Thus make sure<br />
that either module is unloaded or not compiled at all.<br />
; <code>CONFIG_NET_PKTGEN</code><br />
: Networking support -> Networking options -> Network testing -> Packet generator<br />
<br />
=== iproute2 ===<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Building CRIU From Source ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Checking That It Works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Iterative_migration&diff=1553Iterative migration2014-07-03T13:10:28Z<p>Cov: </p>
<hr />
<div>This page describes how to reduce the freeze time of an application by using the [[memory changes tracking]] ability to perform [http://en.wikipedia.org/wiki/Live_migration#Pre-copy_memory_migration pre-copy memory migration].<br />
<br />
{{Note|It is assumed that you already read [[Live migration]] article before this one.}}<br />
<br />
== Migration sequence ==<br />
<br />
The steps below look like those in regular live migration, but include one or more pre-dump stages.<br />
<br />
=== Pre-dump ===<br />
Take tasks you are about to migrate and pre-dump them into some place. Tasks will remain running after pre-dump, unlike regular dump.<br />
<br />
[src]# criu pre-dump --tree <pid> --images-dir <path-to-existing-directory-A><br />
<br />
The directory with images can be on a shared storage, or you can use [[disk-less migration]] to avoid the '''Copy''' step.<br />
<br />
Now you can either proceed to next step and do regular dump, or perform the pre-dump step again. In the latter case pre-dump would generate another set of pre-dump images which will contain memory changed after previous pre-dump. Doing several pre-dump iterations may reduce the amount of data dumped on dump stage and thus lead to shorter freeze time.<br />
<br />
Note, that if you're going to perform more than one pre-dump steps, you should create different directories for images and properly reference them with the <code>--images-dir</code> and the <code>--prev-images-dir</code> for all pre-dump and dump steps.<br />
<br />
=== Dump ===<br />
Now you can do regular dump of your processes.<br />
<br />
[src]# criu dump --tree <pid> --images-dir <path-to-existing-directory-B> \<br />
--prev-images-dir <path-to-directory-A-relative-to-B> --leave-stopped<br />
<br />
Note that:<br />
<br />
# this dump would work faster than without pre-dump, as this dump only takes the memory that has changed since the last pre-dump;<br />
# the <code>--prev-images-dir</code> should contain path to the directory with pre-dump images ''relative to the directory where the dump images will be put''.<br />
<br />
=== Copy ===<br />
Copy images to the destination node:<br />
<br />
[src]# scp -r <path-to-images-dir> <dst>:/<path-to-images><br />
<br />
=== Restore ===<br />
On the destination node restore the apps from images:<br />
<br />
[dst]# criu restore --tree <pid> --images-dir <path-to-images><br />
<br />
=== Kill ===<br />
If everything went OK you can kill stopped tasks on the source node:<br />
<br />
[src]# FIXME put command here<br />
<br />
[[Category: HOWTO]]</div>Covhttps://criu.org/index.php?title=Installation&diff=1532Installation2014-06-19T14:33:44Z<p>Cov: /* Kernel configuration */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes manual installation.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Tools installation ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Before building, make sure you have C bindings for Google's Protocol Buffers installed. In an RPM-based world this is the <code>protobuf-c-devel</code> package, and on Debian and derivatives, <code>libprotobuf-c0-dev</code>.<br />
If for some reason there is no appropriate package for your system available, just install Google's Protocol Buffer from the<br />
source tarball. The protocol buffer library can be found at http://code.google.com/p/protobuf/, while<br />
protocol buffer C binding can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Kernel configuration ==<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options should be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_UTS_NS</code><br />
: General setup -> Namespaces support -> UTS namespace<br />
<br />
; <code>CONFIG_IPC_NS</code><br />
: General setup -> Namespaces support -> IPC namespace<br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
==iproute2==<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking how it works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1531Installation2014-06-19T14:24:09Z<p>Cov: /* Kernel configuration */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. This page describes manual installation.<br />
<br />
{{Note|Most probably you don't need manual installation, but rather [[Packages]] for your distro.}}<br />
<br />
== Tools installation ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=criu.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Before building, make sure you have C bindings for Google's Protocol Buffers installed. In an RPM-based world this is the <code>protobuf-c-devel</code> package, and on Debian and derivatives, <code>libprotobuf-c0-dev</code>.<br />
If for some reason there is no appropriate package for your system available, just install Google's Protocol Buffer from the<br />
source tarball. The protocol buffer library can be found at http://code.google.com/p/protobuf/, while<br />
protocol buffer C binding can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Kernel configuration ==<br />
<br />
Linux kernel v3.11 or newer is required, with some specific options set. If your distribution does not provide needed kernel, you might want to compile one yourself. Note we also have our [[custom kernel]], which might contain some experimental CRIU related patches.<br />
<br />
Note you might have to enable<br />
; <code>CONFIG_EXPERT</code><br />
: General setup -> Configure standard kernel features (expert users)<br />
option, which depends on<br />
; <code>CONFIG_EMBEDDED</code><br />
: General setup -> Embedded system<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
The following options should be enabled for CRIU to work:<br />
<br />
; <code>CONFIG_CHECKPOINT_RESTORE</code><br />
: General setup -> Checkpoint/restore support<br />
<br />
; <code>CONFIG_NAMESPACES</code><br />
: General setup -> Namespaces support <br />
<br />
; <code>CONFIG_PID_NS</code><br />
: General setup -> Namespaces support -> PID namespaces<br />
<br />
; <code>CONFIG_NET_NS</code><br />
: General setup -> Namespaces support -> Network namespace<br />
<br />
; <code>CONFIG_FHANDLE</code><br />
: General setup -> open by fhandle syscalls<br />
<br />
; <code>CONFIG_EVENTFD</code><br />
: General setup -> Enable eventfd() system call<br />
<br />
; <code>CONFIG_EPOLL</code><br />
: General setup -> Enable eventpoll support<br />
<br />
; <code>CONFIG_INOTIFY_USER</code><br />
: File systems -> Inotify support for userspace<br />
<br />
; <code>CONFIG_IA32_EMULATION</code><br />
: Executable file formats -> Emulations -> IA32 Emulation<br />
<br />
; <code>CONFIG_UNIX_DIAG</code><br />
: Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface<br />
<br />
; <code>CONFIG_INET_UDP_DIAG</code><br />
: Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface<br />
<br />
; <code>CONFIG_PACKET_DIAG</code><br />
: Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface<br />
<br />
; <code>CONFIG_NETLINK_DIAG</code><br />
: Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce [[incremental dumps]]. Need to enable<br />
; <code>CONFIG_MEM_SOFT_DIRTY</code><br />
: Processor type and features -> Track memory changes<br />
<br />
==iproute2==<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking how it works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Custom_kernel&diff=1270Custom kernel2013-12-11T11:03:11Z<p>Cov: </p>
<hr />
<div>Currently (as of Linux v3.11) all the CRIU-related kernel patches are in the vanilla upstream kernel. That means there is '''no need for a custom kernel''' anymore. In other words, skip this page.<br />
<br />
In the future, CRIU team might start working on some new kernel stuff for CRIU again. In that case any new patches will first be available from the staging repository at<br />
<br />
* http://git.kernel.org/?p=linux/kernel/git/gorcunov/linux-cr.git<br />
<br />
<br />
Also, a [http://www.raspberrypi.org/ Raspberry Pi] specific kernel is available at<br />
* https://github.com/avagin/linux-rpi-criu/tree/criu-rpi-3.11.y<br />
<br />
[[Category: Development]]<br />
[[Category: HOWTO]]</div>Covhttps://criu.org/index.php?title=Incremental_dumps&diff=1255Incremental dumps2013-12-02T20:30:35Z<p>Cov: </p>
<hr />
<div>If you're doing several dumps in a row, the 2nd and subsequent dumps can be sped up. Here's how:<br />
<br />
== Create the first dump ==<br />
<br />
# mkdir -p <path-to-images>/1/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem<br />
<br />
* Images are put into the <code>1/</code> sub-directory, since we're about to create the 2nd (and more) incremental dumps and it's handy to store them in this way;<br />
* The <code>--leave-running</code> option is used to make criu not kill the tasks after dump, but let them run further;<br />
* The <code>--track-mem</code> option makes criu ask kernel to monitor memory changes to optimize the subsequent dump.<br />
<br />
== Create the second dump ==<br />
<br />
# mkdir <path-to-images>/2/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/2/ --leave-running --track-mem --prev-images-dir ../1/<br />
<br />
* Note, that the <code>--prev-images-dir</code> path is relative to the <code>--images-dir</code> one;<br />
* Similarly the 3rd and all the other dumps can be created.<br />
<br />
== Create the last dump ==<br />
<br />
# mkdir <path-to-images>/N/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/N/ --prev-images-dir ../N-1/<br />
<br />
* No <code>--leave-running</code> option will make tasks be killed after dump;<br />
* No need in memory tracking option.<br />
<br />
== Restore ==<br />
<br />
Now you can restore the processes from whatever images you want<br />
<br />
# criu restore --images-dir <path-to-images>/ANY/<br />
<br />
<br />
{{Note|After each (but the last) dump tasks continue running and thus can modify filesystem. CRIU doesn't snapshot filesystem and assumes, that proper filesystem state for restore is provided by user}}<br />
<br />
[[Category:HOWTO]]</div>Covhttps://criu.org/index.php?title=Incremental_dumps&diff=1254Incremental dumps2013-12-02T20:30:22Z<p>Cov: </p>
<hr />
<div>If you're doing several dumps in a row, the 2nd and subsequent dumps can be speed up. Here's how:<br />
<br />
== Create the first dump ==<br />
<br />
# mkdir -p <path-to-images>/1/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/1/ --leave-running --track-mem<br />
<br />
* Images are put into the <code>1/</code> sub-directory, since we're about to create the 2nd (and more) incremental dumps and it's handy to store them in this way;<br />
* The <code>--leave-running</code> option is used to make criu not kill the tasks after dump, but let them run further;<br />
* The <code>--track-mem</code> option makes criu ask kernel to monitor memory changes to optimize the subsequent dump.<br />
<br />
== Create the second dump ==<br />
<br />
# mkdir <path-to-images>/2/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/2/ --leave-running --track-mem --prev-images-dir ../1/<br />
<br />
* Note, that the <code>--prev-images-dir</code> path is relative to the <code>--images-dir</code> one;<br />
* Similarly the 3rd and all the other dumps can be created.<br />
<br />
== Create the last dump ==<br />
<br />
# mkdir <path-to-images>/N/<br />
# criu dump --tree <pid> --images-dir <path-to-images>/N/ --prev-images-dir ../N-1/<br />
<br />
* No <code>--leave-running</code> option will make tasks be killed after dump;<br />
* No need in memory tracking option.<br />
<br />
== Restore ==<br />
<br />
Now you can restore the processes from whatever images you want<br />
<br />
# criu restore --images-dir <path-to-images>/ANY/<br />
<br />
<br />
{{Note|After each (but the last) dump tasks continue running and thus can modify filesystem. CRIU doesn't snapshot filesystem and assumes, that proper filesystem state for restore is provided by user}}<br />
<br />
[[Category:HOWTO]]</div>Covhttps://criu.org/index.php?title=Installation&diff=1253Installation2013-12-02T13:20:49Z<p>Cov: </p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. <br />
<br />
== Tools installation ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=crtools.git;a=summary git.criu.org] git repository. Clone this repo to test new functionality.<br />
<br />
Before building, make sure you have C bindings for Google's Protocol Buffers installed. In an RPM-based world this is the <code>protobuf-c-devel</code> package, and on Debian and derivatives, <code>libprotobuf-c0-dev</code>.<br />
If for some reason there is no appropriate package for your system available, just install Google's Protocol Buffer from the<br />
source tarball. The protocol buffer library can be found at http://code.google.com/p/protobuf/, while<br />
protocol buffer C binding can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
Then run <code>make</code> in the sources root. Please note that the tool only supports x86_64 and ARM architectures.<br />
<br />
== Kernel configuration ==<br />
<br />
The <code>v3.11</code> upstream kernel already has all the required functionality merged. Make sure you have the following options turned on:<br />
<br />
* General setup -> Checkpoint/restore support (<code>CONFIG_CHECKPOINT_RESTORE</code>)<br />
* General setup -> Namespaces support (<code>CONFIG_NAMESPACES</code>)<br />
* General setup -> Namespaces support -> PID namespaces (<code>CONFIG_PID_NS</code>)<br />
* General setup -> open by fhandle syscalls (<code>CONFIG_FHANDLE</code>)<br />
* General setup -> Enable eventfd() system call (<code>CONFIG_EVENTFD</code>)<br />
* General setup -> Enable eventpoll support (<code>CONFIG_EPOLL</code>)<br />
* File systems -> Inotify support for userspace (<code>CONFIG_INOTIFY_USER</code>)<br />
* Executable file formats -> Emulations -> IA32 Emulation (<code>CONFIG_IA32_EMULATION</code>)<br />
* Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface (<code>CONFIG_UNIX_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface (<code>CONFIG_INET_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface (<code>CONFIG_INET_UDP_DIAG</code>)<br />
* Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface (<code>CONFIG_PACKET_DIAG</code>)<br />
* Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface (<code>CONFIG_NETLINK_DIAG</code>)<br />
<br />
Note you might have to enable<br />
<br />
* General setup -> Configure standard kernel features (expert users) (<code>CONFIG_EXPERT</code>)<br />
<br />
option, which depends on<br />
<br />
* General setup -> Embedded system (<code>CONFIG_EMBEDDED</code>)<br />
<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
For some [[usage scenarios]] there is an ability to track memory changes and produce incremental dumps. Need to enable<br />
* Processor type and features -> Track memory changes (<code>CONFIG_MEM_SOFT_DIRTY</code>)<br />
<br />
<br />
In the future we can start working on some new kernel stuff for CRIU. In that case we will first put this into the staging repository at [http://git.kernel.org/?p=linux/kernel/git/gorcunov/linux-cr.git;a=summary linux-cr.git] ([https://github.com/avagin/linux-rpi-criu/tree/criu-rpi-3.10.y linux-cr-rpi.git] for [http://www.raspberrypi.org/ Raspberry Pi]), so that anyone can checkout the latest branch and compile the kernel.<br />
<br />
<br />
==iproute2==<br />
The iproute2 tool version 3.5.0 or higher is needed for dumping network namespaces.<br />
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 written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking how it works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
{{Out|There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.}}<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1211Installation2013-11-02T14:56:07Z<p>Cov: /* Tools installation */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. <br />
<br />
== Tools installation ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=crtools.git;a=summary git.criu.org] git repository.<br />
Clone this repo to test new functionality.<br />
<br />
Before building, make sure you have C bindings for Google's Protocol Buffers installed. In an RPM-based world this is the <code>protobuf-c-devel</code> package, and on Debian and derivatives, <code>libprotobuf-c0-dev</code>.<br />
If for some reason there is no appropriate package for your system available, just install Google's Protocol Buffer from the<br />
source tarball. The protocol buffer library can be found at http://code.google.com/p/protobuf/, while<br />
protocol buffer C binding can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
Then run <code>make</code> in the sources root.<br />
<br />
== Kernel configuration ==<br />
<br />
The <code>v3.9</code> upstream kernel already has most of the required functionality merged. Some is still out-of-tree though, so you might need to clone the [http://git.kernel.org/?p=linux/kernel/git/gorcunov/linux-cr.git;a=summary linux-cr.git] ([https://github.com/avagin/linux-rpi-criu/tree/criu-rpi-3.10.y linux-cr-rpi.git] for [http://www.raspberrypi.org/ Raspberry Pi]), checkout the latest branch and compile the kernel.<br />
<br />
Make sure you have the following options turned on:<br />
<br />
* General setup -> Checkpoint/restore support (<code>CONFIG_CHECKPOINT_RESTORE</code>)<br />
* General setup -> Namespaces support (<code>CONFIG_NAMESPACES</code>)<br />
* General setup -> Namespaces support -> PID namespaces (<code>CONFIG_PID_NS</code>)<br />
* General setup -> open by fhandle syscalls (<code>CONFIG_FHANDLE</code>)<br />
* General setup -> Enable eventfd() system call (<code>CONFIG_EVENTFD</code>)<br />
* General setup -> Enable eventpoll support (<code>CONFIG_EPOLL</code>)<br />
* File systems -> Inotify support for userspace (<code>CONFIG_INOTIFY_USER</code>)<br />
* Executable file formats -> Emulations -> IA32 Emulation (<code>CONFIG_IA32_EMULATION</code>)<br />
* Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface (<code>CONFIG_UNIX_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface (<code>CONFIG_INET_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface (<code>CONFIG_INET_UDP_DIAG</code>)<br />
* Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface (<code>CONFIG_PACKET_DIAG</code>)<br />
* Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface (<code>CONFIG_NETLINK_DIAG</code>)<br />
<br />
Note you might have to enable<br />
<br />
* General setup -> Configure standard kernel features (expert users) (<code>CONFIG_EXPERT</code>)<br />
<br />
option, which depends on<br />
<br />
* General setup -> Embedded system (<code>CONFIG_EMBEDDED</code>)<br />
<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
Since kernel <code>v3.11</code> there is an ability to track memory changes and produce incremental dumps. Need to enable<br />
* Processor type and features -> Track memory changes (<code>CONFIG_MEM_SOFT_DIRTY</code>)<br />
<br />
==iproute2==<br />
A modified version of iproute2 is needed for dumping network namespaces. The good one can be cloned from<br />
[http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=summary iproute2]. It should be compiled and a path to ip is written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking how it works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Covhttps://criu.org/index.php?title=Installation&diff=1179Installation2013-10-02T13:37:38Z<p>Cov: /* Kernel configuration */</p>
<hr />
<div><code>criu</code> is an utility to checkpoint/restore a process tree. <br />
<br />
== Tools installation ==<br />
<br />
Get the latest release:<br />
{{Out|{{Latest release}}}}<br />
<br />
Alternatively, use [http://git.criu.org/?p=crtools.git;a=summary git.criu.org] git repository.<br />
Clone this repo to test new functionality.<br />
<br />
Before building, make sure you have C bindings for Google's Protocol Buffers installed. In rpm-based world this is <code>protobuf-c-devel</code> package.<br />
If for some reason there is no appropriate package for your system available, just install Google's Protocol Buffer from the<br />
source tarball. The protocol buffer library can be found at http://code.google.com/p/protobuf/, while<br />
protocol buffer C binding can be found at http://code.google.com/p/protobuf-c/.<br />
<br />
Then run <code>make</code> in the sources root.<br />
<br />
== Kernel configuration ==<br />
<br />
The <code>v3.9</code> upstream kernel already has most of the required functionality merged. Some is still out-of-tree though, so you might need to clone the [http://git.kernel.org/?p=linux/kernel/git/gorcunov/linux-cr.git;a=summary linux-cr.git] ([https://github.com/avagin/linux-rpi-criu/tree/criu-rpi-3.10.y linux-cr-rpi.git] for [http://www.raspberrypi.org/ Raspberry Pi]), checkout the latest branch and compile the kernel.<br />
<br />
Make sure you have the following options turned on:<br />
<br />
* General setup -> Checkpoint/restore support (<code>CONFIG_CHECKPOINT_RESTORE</code>)<br />
* General setup -> Namespaces support (<code>CONFIG_NAMESPACES</code>)<br />
* General setup -> Namespaces support -> PID namespaces (<code>CONFIG_PID_NS</code>)<br />
* General setup -> open by fhandle syscalls (<code>CONFIG_FHANDLE</code>)<br />
* General setup -> Enable eventfd() system call (<code>CONFIG_EVENTFD</code>)<br />
* General setup -> Enable eventpoll support (<code>CONFIG_EPOLL</code>)<br />
* File systems -> Inotify support for userspace (<code>CONFIG_INOTIFY_USER</code>)<br />
* Executable file formats -> Emulations -> IA32 Emulation (<code>CONFIG_IA32_EMULATION</code>)<br />
* Networking support -> Networking options -> Unix domain sockets -> UNIX: socket monitoring interface (<code>CONFIG_UNIX_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface (<code>CONFIG_INET_DIAG</code>)<br />
* Networking support -> Networking options -> TCP/IP networking -> INET: socket monitoring interface -> UDP: socket monitoring interface (<code>CONFIG_INET_UDP_DIAG</code>)<br />
* Networking support -> Networking options -> Packet socket -> Packet: sockets monitoring interface (<code>CONFIG_PACKET_DIAG</code>)<br />
* Networking support -> Networking options -> Netlink socket -> Netlink: sockets monitoring interface (<code>CONFIG_NETLINK_DIAG</code>)<br />
<br />
Note you might have to enable<br />
<br />
* General setup -> Configure standard kernel features (expert users) (<code>CONFIG_EXPERT</code>)<br />
<br />
option, which depends on<br />
<br />
* General setup -> Embedded system (<code>CONFIG_EMBEDDED</code>)<br />
<br />
(welcome to Kconfig reverse chains hell).<br />
<br />
Since kernel <code>v3.11</code> there is an ability to track memory changes and produce incremental dumps. Need to enable<br />
* Processor type and features -> Track memory changes (<code>CONFIG_MEM_SOFT_DIRTY</code>)<br />
<br />
==iproute2==<br />
A modified version of iproute2 is needed for dumping network namespaces. The good one can be cloned from<br />
[http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=summary iproute2]. It should be compiled and a path to ip is written in the environment variable <code>CR_IP_TOOL</code>.<br />
<br />
== Checking how it works ==<br />
<br />
First thing to do is to run<br />
<br />
<pre><br />
# criu check --ms<br />
</pre><br />
<br />
At the end it should say "Looks OK", if it doesn't the messages on the screen explain what functionality is missing.<br />
If you're using our custom kernel, then the <code>--ms</code> option should not be used, in this case CRIU would<br />
check for ''all'' the kernel features to work.<br />
<br />
You can then try running the [[ZDTM Test Suite]] which sits in the <code>tests/zdtm/</code> directory.<br />
<br />
== Using CR tools ==<br />
<br />
Please see [[Usage]] and [[Advanced usage]], as well as [[:Category:HOWTO]].</div>Cov