What cannot be checkpointed - Revision history

Radostin at 10:02, 25 February 2022

2022-02-25T10:02:24Z

2017-07-13T12:53:36Z

Half-opened UNIX connections

2017-07-13T12:53:29Z

Files sent over unix sockets

2017-05-04T18:29:27Z

Cannot be dumped (yet): I guess, it's time to remove compat from can't be dumped as for v3.0 :)

2016-09-21T08:02:57Z

Cannot be dumped (yet)

2016-09-21T08:02:18Z

Dumped with special option

2016-09-15T18:50:00Z

2016-09-08T22:29:40Z

UNIX sockets with relative path: FIXED

2016-09-08T22:29:19Z

Task from a different user (for non-root)

2014-12-01T14:59:41Z

Dump/restore of graphical applications =

← Older revision		Revision as of 10:02, 25 February 2022
Line 31:		Line 31:

	The explanation why device file cannot be dumped and restored in a generic way is two fold. First of all, application can be dumped for live migration and on restore there can be no such device. But that's easy. Other than this, we don't know how all the devices work. App might have loaded some state into it, and in order to dump it properly we need to fetch that state. This is not something that can be done in a generic manner.		The explanation why device file cannot be dumped and restored in a generic way is two fold. First of all, application can be dumped for live migration and on restore there can be no such device. But that's easy. Other than this, we don't know how all the devices work. App might have loaded some state into it, and in order to dump it properly we need to fetch that state. This is not something that can be done in a generic manner.
		+
		+	=== Open files from unmounted filesystem ===
		+
		+	When a busy filesystem is "lazy" unmounted any references to it are cleaned up as soon as the filesystem is not busy anymore.
		+	If a process has an open file from a lazy-umounted filesystem, CRIU just can't checkpoint/restore this process, unless the file is closed.
		+
		+	''See also: [[Dumping files]]''

	=== Tasks with debugger attached ===		=== Tasks with debugger attached ===

@@ Line 52: / Line 52: @@
 === Files sent over unix sockets ===
 {{Bug|251}}
 === SysVIPC memory segment w/o IPC namespace ===

← Older revision		Revision as of 12:53, 13 July 2017
Line 51:		Line 51:

	=== Files sent over unix sockets ===		=== Files sent over unix sockets ===
		+	{{Bug\|251}}

	=== Half-opened UNIX connections ===		=== Half-opened UNIX connections ===

← Older revision		Revision as of 18:29, 4 May 2017
Line 41:		Line 41:

	''See also: [[User-mode]]''		''See also: [[User-mode]]''
−
−	~~=== Task running in compat mode (x86-64) ===~~
−
−	~~We don't yet support 32 bit tasks. Though it should be fixed with time.~~

	=== Sockets other than TCP, UDP, UNIX, packet and netlink ===		=== Sockets other than TCP, UDP, UNIX, packet and netlink ===

← Older revision		Revision as of 08:02, 21 September 2016
Line 53:		Line 53:

	=== Cork-ed UDP sockets ===		=== Cork-ed UDP sockets ===
		+
		+	=== Files sent over unix sockets ===
		+
		+	=== Half-opened UNIX connections ===

	=== SysVIPC memory segment w/o IPC namespace ===		=== SysVIPC memory segment w/o IPC namespace ===

@@ Line 10: / Line 10: @@
 By default CRIU allows to dump the set of processes and their resources if this set has no connections outside. However, in some situations it makes sense to ignore this external connection on dump and recreate one on restore. So, what this "connection outside" is? For example:
-* '''UNIX socket'''. Application may have a UNIX socket connected to some other app and the latter one is not dumped. This is called [[external UNIX socket]].
+''Main article: [[External resources]]''
 === File locks ===
 A file lock is an object, that belongs to some filesystem. On dump it's impossible to find out whether this lock help by one task ''can'' be used by some other. Thus, CRIU doesn't dump tasks with held locks. The <code>--file-locks</code> CLI option tells CRIU to dump the lock.
 == Cannot be dumped (yet) ==

← Older revision		Revision as of 18:50, 15 September 2016
Line 55:		Line 55:
	== Dump/restore of graphical applications ==		== Dump/restore of graphical applications ==
	Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.		Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.
		+
		+	[[Category:Using]]

← Older revision		Revision as of 22:29, 8 September 2016
Line 40:		Line 40:

	We don't yet support 32 bit tasks. Though it should be fixed with time.		We don't yet support 32 bit tasks. Though it should be fixed with time.
−
−	~~=== UNIX sockets with relative path ===~~
−
−	For bound unix sockets kernel only provides the path with this the bind() syscall was called. If the path is relative we have no reliable way to find the exact socket location out and just refuse to dump the task.

	=== Sockets other than TCP, UDP, UNIX, packet and netlink ===		=== Sockets other than TCP, UDP, UNIX, packet and netlink ===

← Older revision		Revision as of 22:29, 8 September 2016
Line 34:		Line 34:

	For security reasons, if CRIU is requested by non-root to dump some other task, it doesn't do it unless the dumpee belongs to the same user.		For security reasons, if CRIU is requested by non-root to dump some other task, it doesn't do it unless the dumpee belongs to the same user.
		+
		+	''See also: [[User-mode]]''

	=== Task running in compat mode (x86-64) ===		=== Task running in compat mode (x86-64) ===

@@ Line 55: / Line 55: @@
 IPC objects are not tied to any tasks. Thus once CRIU meets an IPC memory attached to a task, it requires the whole IPC namespace to be dumped as well.
-== Dump/restore of graphical applications ===
+== Dump/restore of graphical applications ==
 Dumping + restoring an application connected to a "real" Xserver (e.g. on your laptop) is impossible now due to part of the app's state is in the Xserver and we don't dump this.