When C/R fails - Revision history

Brlin: /* Restore "by hand" */ Fix typo

2020-08-03T09:25:56Z

Restore "by hand": Fix typo

Rppt: some English rephrasing

2016-11-04T02:37:38Z

some English rephrasing

Xemul: /* PID mismatch on restore */

2016-09-29T09:24:04Z

PID mismatch on restore

Xemul at 18:48, 15 September 2016

2016-09-15T18:48:53Z

Xemul at 18:47, 15 September 2016

2016-09-15T18:47:55Z

Xemul: Don't recomment unsharing pidns with old proc

2016-06-28T10:26:12Z

Don't recomment unsharing pidns with old proc

Xemul at 14:15, 31 December 2014

2014-12-31T14:15:49Z

Xemul at 14:12, 31 December 2014

2014-12-31T14:12:00Z

Xemul at 14:03, 31 December 2014

2014-12-31T14:03:00Z

Xemul: Created page with "This page is the collection of typical situations when checkpoint or restore fails."

2014-12-31T13:56:41Z

Created page with "This page is the collection of typical situations when checkpoint or restore fails."

New page

This page is the collection of typical situations when checkpoint or restore fails.

@@ Line 17: / Line 17: @@
 One way is to restore the images into a separate pid namespace. This can be done by using the <code>unshare -p -m --fork --mount-proc</code> command and then doing the restore. In this case, you might also want to unshare the mount namespace and re-mount the /proc, so that the restored tasks can use it. This method effectively means restoring tasks in a container.
-Note, however, that them most correct way is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
+Note, however, that the most correct way is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
 === Kill the obstacle ===

@@ Line 3: / Line 3: @@
 == PID mismatch on restore ==
-If you see one of these lines in failed restore logs
+If you see one of these lines in the failed restore logs
 <pre>
@@ Line 12: / Line 12: @@
 </pre>
-this means that while restoring a process tree CRIU has failed to recreate a process or a thread with the PID (TID) value it used to have on dump. This most likely is due to the PID/TID value in question being busy with some other task or thread. There are several possible solutions to this.
+this means that while restoring a process tree, CRIU has failed to recreate a process (or a thread) with the PID (TID) value the proceess (thread) used to have on dump. Most likely, this is because the desired PID/TID is used by other task or thread. There are several possible solutions to this.
-=== Restore "by hands" ===
+=== Restore "by hand" ===
-One is to restore the images into a separate pid namespace. This can be done by using the <code>unshare -p -m --fork --mount-proc</code> command and then doing the restore. In this case you might also want to unshare the mount namespace and re-mount the /proc so that the restored tasks can use it. This method effectively means restoring tasks in container.
+One way is to restore the images into a separate pid namespace. This can be done by using the <code>unshare -p -m --fork --mount-proc</code> command and then doing the restore. In this case, you might also want to unshare the mount namespace and re-mount the /proc, so that the restored tasks can use it. This method effectively means restoring tasks in a container.
-Having said the above, the most correct way to handle this is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
+Note, however, that them most correct way is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
 === Kill the obstacle ===
-Another solution to PID mismatch, not correct, but still, is in killing the offending task :)
+Another solution to PID mismatch, which is not correct, but still efficient, is to kill the offending task :)
 === With CRIU help ===

@@ Line 14: / Line 14: @@
 this means that while restoring a process tree CRIU has failed to recreate a process or a thread with the PID (TID) value it used to have on dump. This most likely is due to the PID/TID value in question being busy with some other task or thread. There are several possible solutions to this.
 One is to restore the images into a separate pid namespace. This can be done by using the <code>unshare -p -m --fork --mount-proc</code> command and then doing the restore. In this case you might also want to unshare the mount namespace and re-mount the /proc so that the restored tasks can use it. This method effectively means restoring tasks in container.
 Having said the above, the most correct way to handle this is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
 Another solution to PID mismatch, not correct, but still, is in killing the offending task :)
 == Mount namespace with external dependences ==

← Older revision		Revision as of 18:48, 15 September 2016
Line 40:		Line 40:

	In this case the socket should be explained as "OK to break" and reconnected back on restore. How to do it is described in [[external UNIX socket\|here]]		In this case the socket should be explained as "OK to break" and reconnected back on restore. How to do it is described in [[external UNIX socket\|here]]
		+
		+	[[Category:Using]]

← Older revision		Revision as of 18:47, 15 September 2016
Line 30:		Line 30:

	indicates that the container (or just mount namespace) being dumped has some external dependences. CRIU knows how to work with it, you just need to tell CRIU about [[external bind mounts]] you have.		indicates that the container (or just mount namespace) being dumped has some external dependences. CRIU knows how to work with it, you just need to tell CRIU about [[external bind mounts]] you have.
		+
		+	== External unix socket connection ==
		+
		+	If an application has an open unix connection to the external world, the dump will fail with
		+
		+	<pre>
		+	"Cannot dump half of a stream unix connection
		+	</pre>
		+
		+	In this case the socket should be explained as "OK to break" and reconnected back on restore. How to do it is described in [[external UNIX socket\|here]]

← Older revision		Revision as of 14:15, 31 December 2014
Line 19:		Line 19:

	Another solution to PID mismatch, not correct, but still, is in killing the offending task :)		Another solution to PID mismatch, not correct, but still, is in killing the offending task :)
		+
		+
		+	== Mount namespace with external dependences ==
		+
		+	The dump-time error in logs
		+
		+	<pre>
		+	$nr:$path doesn't have a proper root mount
		+	</pre>
		+
		+	indicates that the container (or just mount namespace) being dumped has some external dependences. CRIU knows how to work with it, you just need to tell CRIU about [[external bind mounts]] you have.

← Older revision		Revision as of 14:12, 31 December 2014
Line 12:		Line 12:
	</pre>		</pre>

−	this means that while restoring a process tree CRIU has failed to recreate a process or a thread with the PID (TID) value it used to have on dump. This most likely is due to the PID/TID value in question being busy with some other task or thread.	+	this means that while restoring a process tree CRIU has failed to recreate a process or a thread with the PID (TID) value it used to have on dump. This most likely is due to the PID/TID value in question being busy with some other task or thread. There are several possible solutions to this.
		+
		+	One is to restore the images into a separate pid namespace. This can be done by using the <code>unshare -p --fork</code> command and then doing the restore. In this case you might also want to unshare the mount namespace and re-mount the /proc so that the restored tasks can use it. This method effectively means restoring tasks in container.
		+
		+	Having said the above, the most correct way to handle this is to run the tasks you plan to checkpoint in the pid namespace (with /proc tune-up if required) from the very beginning.
		+
		+	Another solution to PID mismatch, not correct, but still, is in killing the offending task :)

← Older revision		Revision as of 14:03, 31 December 2014
Line 1:		Line 1:
	This page is the collection of typical situations when checkpoint or restore fails.		This page is the collection of typical situations when checkpoint or restore fails.
		+
		+	== PID mismatch on restore ==
		+
		+	If you see one of these lines in failed restore logs
		+
		+	<pre>
		+	Pid $number do not match expected $another_number
		+	</pre>
		+	<pre>
		+	Thread pid mismatch $number1/$number2
		+	</pre>
		+
		+	this means that while restoring a process tree CRIU has failed to recreate a process or a thread with the PID (TID) value it used to have on dump. This most likely is due to the PID/TID value in question being busy with some other task or thread.