- 30 Oct, 2018 40 commits
-
-
Cyrill Gorcunov authored
To find target files with help of our collected rbtree. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
If we can't find target file descriptor we should exit on dump with error instead of skipping it. Signed-off-by:
-
Cyrill Gorcunov authored
We will use them to fast lookup of targets files. Signed-off-by:
-
Cyrill Gorcunov authored
To run epoll tests only where it is supported. Signed-off-by:
-
Cyrill Gorcunov authored
For readability sake Signed-off-by:
-
Cyrill Gorcunov authored
To figure out efd:tfd mapping easier by reading the logs. Signed-off-by:
-
Cyrill Gorcunov authored
For easier fd match when reading logs Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
When target file obtained from epoll fdinfo (internally the kernel keeps only file _number_ inside) we have to check its identity to make sure it is exactly one which has been added into epoll engine. The only proper way is to use kcmp syscall. Signed-off-by:
-
Cyrill Gorcunov authored
When we are checkpoiting epoll targets we assuming that this target file is belonging to the process we are on. This is of course not true. Without kernel support the only thing we can do is compare fd numbers with ones present in epoll fdinfo. When fd numer match we assume that it indeed the file which has been added into epoll. This won't cover the case when file has been moved to some other number and new one is reopened instead of it. Such scenario will trigger false positive and we can't do anything about. In next patches with kernel help we will make precise check for files identity. Signed-off-by:
-
Cyrill Gorcunov authored
In epoll dumping we will need the whole set of fds to investigate the targets, so pass this parameter down to epoll code. Signed-off-by:
-
Cyrill Gorcunov authored
We will need it to make sure the target files in epolls are present in current process. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Cyrill Gorcunov authored
- aling memebers - use pid_t type for PIDs Signed-off-by:
-
Cyrill Gorcunov authored
- switch to use uintX type (just to drop uX finally, it doesn't worth to carry this type) - instead of including huge util.h rather include the files which are really needed: log, xmalloc, compiler and bug Signed-off-by:
-
Andrei Vagin authored
Signed-off-by: -
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Kirill Tkhai authored
Before this patch we used flock to order task creation, but this way is not good. It took 5 syscalls to synchronize a creation of a single child: 1)open() 2)flock(LOCK_EX) 3)flock(LOCK_UN) 4)close() in parent 5)close() in child The patch introduces more effective way for synchronization, which executes 2 syscalls only. We use last_pid_mutex, and the syscalls number sounds definitely better. v2: Don't use flock() at all Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
Kirill Tkhai authored
Introduce mutex for synchronization ns_last_pid file on restore. Signed-off-by:
-
Dmitry Safonov authored
I think, we should warn a user when we can't C/R compatible applications. That's valid for different than x86 archs. Let's correct the message the way it'll suit non-x86. Reported-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
-
Andrei Vagin authored
vma_area_list@entry=0x818) at criu/cr-dump.c:107 107 list_for_each_entry_safe(vma_area, p, &vma_area_list->h, list) Signed-off-by: -
Andrei Vagin authored
When a non-root user runs "criu restore" and criu has the suid bit, a process will run with non-zero uid and gid. Before the 4.13 kernel (4d28df6152aa "prctl: Allow local CAP_SYS_ADMIN changing exe_file"), PR_SET_MM_EXE_FILE fails if uid or gid isn't zero. Signed-off-by: -
Adrian Reber authored
Install sudo, create test user with ID 1000, install bash, fix pidfile creation and pidfile chmod. v2: * use sleep to give the criu daemon some time to start up v3: * Andrei is of course right and sleep is not good solution. After adding --status-fd support to criu service, this is how we now detect that criu is ready. v4: * This was much more complicated than expected which is related to the different versions of the tools on the different travis test targets. There seems to be a bug in bash on Ubuntu https://lists.gnu.org/archive/html/bug-bash/2017-07/msg00039.html which prevents using 'read -n1' on Ubuntu. As a workaround the result from CRIU's status FD is now read via python. Another problem was discovered on alpine with the loop restore test. CRIU says to use setsid even if the process is already using setsid. As a workaround, still with setsid, this process is now using shell-job true for checkpoint and restore. Parts of v2 have been committed before. So the changes from this commit are partially already in another commit. Signed-off-by: -
Adrian Reber authored
Make the --status-fd option also work in 'criu service' mode to avoid race conditions during testing. Signed-off-by:
-
Adrian Reber authored
Install sudo, create test user with ID 1000, install bash, fix pidfile creation and pidfile chmod. v2: * use sleep to give the criu daemon some time to start up Signed-off-by:
-
Adrian Reber authored
Signed-off-by:
-
Adrian Reber authored
This extends the test.py to also run the RPC command VERSION via 'criu service'. It was already running using 'criu swrk'. Signed-off-by:
-
Adrian Reber authored
In this directory there are various test cases using CRIU in RPC mode (or SWRK mode). This fixes the broken tests by moving the start of 'criu service' from run.sh to the Makefile as the test cases is running using "sudo -g '#1000' -u '#1000'" and the PID file created by CRIU can only be read by the root user. If starting the 'criu service' before run.sh the PID file still can be changed to 0666 and fixing the test script. This also adds version.py to the test cases that are executed. Signed-off-by:
-
Andrei Vagin authored
Return an error if we meet unexpected parameters in a config file Cc: Veronika Kabatova <vkabatov@redhat.com> Signed-off-by: -
Andrei Vagin authored
Now we rely on scanf, that it will initializes a pointer to NULL, when it fails to parse a string, but I can't find in a man page, that it has to do this. Signed-off-by: -
Andrei Vagin authored
Otherwise lines started with spaces are ignored. Cc: Veronika Kabatova <vkabatov@redhat.com> Signed-off-by: -
Mike Rapoport authored
Instead of pre-parsing command line twice, one time to detect -h/--help and another time to find config file parameter, check for both in one pass. Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
-
Mike Rapoport authored
When config parsing was split into a separate part the handling of -h/--help option during init_config was broken. Fix it. Signed-off-by:
-
Mike Rapoport authored
s/first_count/global_cfg_argc s/second_count/user_cfg_argc Signed-off-by:
-
Mike Rapoport authored
Currently kerndat_init() runs before command line parsing and running simple 'criu --version' command may produce something like: Warn (criu/kerndat.c:847): Can't load /run/criu.kdat Error (criu/util.c:842): exited, status=3 Error (criu/util.c:842): exited, status=3 Write 4294967295 to /proc/self/loginuid failed: Operation not permittedWarn (criu/net.c:2732): Unable to get socket network namespace Warn (criu/net.c:2732): Unable to get tun network namespace Warn (criu/sk-unix.c:213): sk unix: Unable to open a socket file: Operation not permitted Error (criu/net.c:3023): Unable create a network namespace: Operation not permitted Warn (criu/net.c:3069): NSID isn't reported for network links Version: 3.6 GitID: v3.6-611-g0b27d0a Group early calls to kerndat_* and init_service_fd calls into a function and call this function after the command line parsing is finished. Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
