Makes the criu RPC socket socket-activated with
systemd [1], meaning that systemd will create and listen to
the UNIX socket /var/run/criu-srvice.socket
on behalf of criu until a connection comes in, when it will
then pass control of the socket, along with the first connection
over to a newly spawned criu daemon.
This is similar to inetd, but criu stays around after getting
started, listening itsself on the socket.
[1] http://0pointer.de/blog/projects/socket-activation.html
v2: stripped down sd-daemon.[ch]
moved units to scripts/sd
v3: stripped down further by removing unneeded includes
Signed-off-by: Shawn Landden <shawn@churchofgit.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It is been found that BTRFS uses per subvolume device
numbering scheme which causes some of our tests to fail
if they are laying on this filesystem.
Here we introduce minimal engine which parses subvolumes
present on mount point.
The interface is two functions
- btrfs_parse_mountinfo: this one parses subvolume and caches the results
- is_btrfs_subvol: test if device id is laying on subvolume
In the code we assume that cpu we're running on
is little endian, thus if one day we run on big
ending machine the code must be updated accordingly.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On restore we need differetn types of memory allocation.
Here's an engine that tries to generalize them all. The
main difference is in how the buffer with objects is being
grown up.
There are 3 types of memory allocations:
1. shared memory -- objects, that will be used by all criu
children, but will not reach the restorer
2. shared remapable -- the same, but restorer would need
access to them, i.e. -- buffer with objects will get
remapped into restorer
3. private -- the same, but allocatedby each task for itself
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Right now we have an ability to launch the C/R service from root
and execure dump requests from unpriviledged users. Not to be bad
guys, we deny dumping tasks belonging to user, that cannot be
"watched" (traced, read /proc, etc.) by the dumper.
In the future we will use this "engine" when launched with suid
bit, and (probably) will have more sophisticated policy.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The criu service is a daemon, that opens a unix socket and listens for
incoming requests. The requests will be declared in protobuf/rpc.proto
and for now will only contain the 'dump' request.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Same as kernel provides, adopted from Linux sources.
strlcpy is similar to strncpy but _always_ adds \0
at the end of string even if destination is shorter.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These contain linkage between number, data type and routines
for pb messages we write/read to/from image files. Most of them
have simple number-type-routines mapping, so introduce a generating
script for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There will be two entities handled:
1. tun file -- an opened char device with misc major and tun minor
that can be attached to item #2
2. tun netdevice -- another type of links
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move image object descriptors to own image-desc
file(s). This allow to reuse the code in other tools.
I had to move show declarations to cr-show.h as well.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move protobuf object descriptors to own protobuf-desc
file(s). This allow to reuse the code in other tools.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
During criu startup we need to fill symbol table of own
run-time vdso provided by the kernel. We will need this
data for vdso proxy.
Because this functions are not used in restorer code,
we move them out of PIE (since PIE code must remain
as small as possible).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll have one more "image" file generated by dump and (surprisingly)
restore commands -- the stats one. It will contain in a single pb
object all the statistics collected by dump/restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
One of such things we use right now is the device for anon shmem
mappings backing. In the furure this can be extended to check for
various kernel features.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Now we have 2 forms of storing pages -- legacy pages.img and
new pagemap + pages image. We'll have one more (ovz) and the
pagemap + pages will be stacked (snapshot restore). Thus it's
handy to have this as an page-reader object.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll send them over network soon, so prepare abstraction layer for
this. Shmem is not on this scheme yet.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The page-pipe is an object, that can accumulate pages inside it. It
consists of list of page-pipe-bufs, which in turn has a pipa, an
array of iovecs that describe the pages' locations and some stats.
Users of it are supposed to vmsplice pages into pipes to accumulate
then for later use, and vmsplice them from pipes when required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
They are really depends on CPU we're running on.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is a bit tricky since the build infrastructure
we're switching to is targeted to per-directory targets
if simplified Makefiles are used.
So I did the following
- move rules to compile general sources to Makefile.crtools
- main Makefiles now simply calls for scritps/Makefile.build
help to generate built-in.o target
Also note that we clean up suffixes for implicit rules with
.SUFFIXES:
this is done on purpose to eliminate any possible side effect
in future -- all rules _must_ be described explicitly.
Because of implicit rules used in zdtm building procedure
I can't use of stict makefile mode and add
MAKEFLAGS := -r
to the top of the general Makefile. This should be done
one day latter (if ever).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
