It's a feature of PTRACE_SEIZE. So we need to do something, only
if we want to change the state.
[xemul: If task _was_ in stopped state before dump and we want them
to stay alive after dump, the existing code queues one more STOP
to it. This affects subsequent dump, as we seize a stopped task
with STOP in queue.
One more item in TODO list -- support stopped tasks with STOP in
queue :)
]
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Before this patch crtools freezes processes and if something is changed,
it unfreezes all processes and starts again from the beginning.
If if are going to dump fork-bomb, this method doesn't work. Because a
big tree is always changed.
We don't need unfreeze processes, which have been frozen and this patch
does that.
This patch uses depth-first search (DFS) for traversing a process tree.
A root task is frozen at first turn, than a child is frozen, than a
child of child and so on.
When all children of one process are frozen, criu reads the list of
children again and check that nothing changed. This processes continues
until all of them will not be frozen. Afte that a new child can not be
appeared, because all children for children are frozen too.
v2: add comments in code
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When we try to freeze threads, some of them can exit
and a few new ones can be born. Currently we unfreeze process free
int this case, so we have the same chance to failed in the next case.
I suggest to not unfreeze frozen threads, just try to update thread list
and freeze unfrozen threads.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently all task are restored as alive, but stopped tasks
must be restored as stopped.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It is not needed, because stat is a property of task,
so we can restore a state of task and it should be enough.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Libraries (plugins) is going to be used for dumping and restoring
external dependencies (e.g. dbus, systemd journal sockets, charecter
devices, etc)
A plugin can have the cr_plugin_init() and cr_plugin_fini functions for
initialization and deinialization.
criu-plugin.h contains all things, which can be used in plugins.
v2: rename lib to plugin
v3: add a default value for a plugin path.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
For paths resolution we will need mount tree to be parsed
and built, but it's not that simple -- the current code
implies that once parsed the tree must not be re-parsed
again, so we pass @parse argument from a caller: if a task
we're restoring do not use mount namespace, we should parse
mount tree early, otherwise defer this action until mount
tree is read from the image.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case if checkpoint is failed or -R option passed
we need to remove link remap files created during
dump procedure.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's been found that if -R (leave task running after checkpoint)
option passed we don't unlock network, nether we clean service
files (such as link remaps).
After a long discussion we choose the following path: if -R option
is passed, it means a user is quite confident in what he is doing
and consistency of the resources (file system) is achieved by
a user himself with help of post-dump script. Also a user knows
that the network will be unlocked and accept such case.
So here we check of -R being passed in command line and once
checkpoint complete we unlock the network.
Cleaning up of link remaps is addressed in another patch.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Don't carry it around in a static global variable. Would
be useful for pidns leaks (processes entered one) scan.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's not enough to check only uids on dump and restore -- we need to
check e-ids and s-ids now (and caps in the future).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When dump/pre-dump failed before initializing vmas, free_mappings(&vmas)
is called and this cause segfault. Lets initialize vmas in the very
beginning of dump.
Signed-off-by: Ruslan Kuprieiev <kurpuser@gmail.com>
seqfault.patch
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>
Currently we catch processes on the exit point from sigreturn.
If a task must be restored in the stopped state, we can send SIGSTOP
before detaching from it.
v2: add more descriptive comment about skipping SIGSTOP in ptrace.c
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we take pid and core from it and we are going to take state.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
parse_thread allocated a buffer for threads and then it initialized read
pid for each thread.
Now we want to use it on restore and in this moment we already have
a buffer with initialized virt pid-s, so we need to initialize read
pid-s only.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It will be used in cr-restore.c for stopping threads on the exit from
sigreturn.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is for security -- service is run from root, but serves requests from non-root
processes. Thus, we shouldn't allow for anyone to dump suid programs that a run from
under unpriviledged processes.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
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>
Restore stats are difficult -- we have to collect them from several
tasks and thus existing plain variables would not work. We'll need
shared memory with stats, so prepre for allocating one.
Other than this -- put call to write_stats() where appropriate for
restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently criu sends data to the page server, but it doesn't get any
feedback, so it can't be sure that all data have been accepted.
This patch adds a flush command, which requires an answer from the page
server. This command is sent before disconnecting.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is usefull if one needs to do some final action before checkpoint
is complete. For example in case of online migration one may provide
a script which would check the restore procedure on remote note
ended without errors, thus the script returns zero code and criu
simply kills running instance of application.
In turn, if migration failed, the script can return nonzero code
and criu won't kill the application but continue its execution
instead.
https://bugzilla.openvz.org/show_bug.cgi?id=2583
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There are parts dumping which is common to thread and task,
and this stuff is represented by parasite_dump_thread structure.
Merge this into parasite_dump_misc and facror out dumping code.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The initilization stage is not good for that, because it can fail.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise we lost 1:1 mapping between names being
dumped and what user sees after restore.
| 1455 pts/0 T 0:00 \_ ./crtools restore -t 1448
| 1448 ? Ss 0:00 | \_ ./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
| 1449 ? Z 0:00 | \_ [zombie00] <defunct>
| 1450 ? Z 0:00 | \_ [zombie00] <defunct>
| 1451 ? Z 0:00 | \_ [zombie00] <defunct>
| 1452 ? Z 0:00 | \_ [zombie00] <defunct>
https://bugzilla.openvz.org/show_bug.cgi?id=2635
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This mask should be put into sigframe (used by parasite, coming
soon) thus we have to pull one from dumpee early.
Plus, check that signals are blocked for each thread separately
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise a task can start to handle a signal and registers can be
changed.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently it's always stopped, but it will be changed, when a parasite
will be executed as a daemon.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
