AutoFS - Revision history

Skinsbursky: /* Tricks */

2016-06-30T13:23:43Z

Tricks

Skinsbursky: /* Tricks */

2016-06-30T13:23:24Z

Tricks

Skinsbursky: /* Limitations */

2016-06-30T13:22:27Z

Limitations

Skinsbursky at 11:36, 10 May 2016

2016-05-10T11:36:48Z

Kir: Typos, punctuation, wording

2016-04-22T16:01:45Z

Typos, punctuation, wording

Skinsbursky at 15:58, 22 April 2016

2016-04-22T15:58:43Z

Skinsbursky at 15:07, 22 April 2016

2016-04-22T15:07:05Z

Skinsbursky at 14:59, 22 April 2016

2016-04-22T14:59:16Z

Skinsbursky at 14:58, 22 April 2016

2016-04-22T14:58:59Z

Skinsbursky at 14:45, 22 April 2016

2016-04-22T14:45:37Z

@@ Line 31: / Line 31: @@
 == Tricks ==
-To overcome systemd's limitation, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
+To overcome <code>systemd</code> limitation, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
 This script is aimed to be used with CRIU option <code>--action-script</code> on restore to fix the issue for those systemd services, which can be painlessly restarted.

@@ Line 31: / Line 31: @@
 == Tricks ==
-To overcome the above limitation, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
+To overcome systemd's limitation, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
 This script is aimed to be used with CRIU option <code>--action-script</code> on restore to fix the issue for those systemd services, which can be painlessly restarted.

@@ Line 11: / Line 11: @@
 CRIU supports both direct (offset) and indirect AutoFS mount points migration.
-However, there is a limitation in migrating of systemd services using AutoFS.
+But CRIU reconstructs AutoFS mount point on restore with different device ID and root inode number.
-The root of the limitation is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each AutoFS-related request from kernel side, and if they do not match, it ignores the request.
+The root of these limitations is that AutoFS master (process, serving AutoFS requests from kernel side) can save AutoFS mount point device ID (and root inode number) in its internals and then compare saved value(s) with received ones on each kernel request. If these values do not match, it can ignore the request.
-CRIU reconstructs AutoFS mount point on restore with different device ID, thus systemd doesn't recognize it anymore.
+Known Autofs masters:
-In user world it means that any access to AutoFS mount point served by systemd will stuck. Restart of the service solves this issue.
+# <code>systemd</code>: AutoFS-based services
 == Tricks ==

← Older revision		Revision as of 11:36, 10 May 2016
Line 30:		Line 30:

	Currently, it only restarts one service, <code>proc-sys-fs-binfmt_misc.automount</code>. Surely, it can be easily extended to support any other.		Currently, it only restarts one service, <code>proc-sys-fs-binfmt_misc.automount</code>. Surely, it can be easily extended to support any other.
		+
		+	The logic of the script is the following:
		+
		+	# Mount aside the file system, located on top of autofs (if any)
		+	# Restart systemd service
		+	# Unmount new file system, appeared on top of restarted autofs (if any)
		+	# Move original file system on top of autofs mount point
		+
		+	Please, note, that the sequence above works only for direct (offset) autofs mount points, when autofs mount point is being overmounted by the desired one.
		+	In case of indirect autofs mount point the content (any mounted file system) will be lost.
		+
		+	== Tricks vs Mount namespaces without propagation ==
		+
		+	There is a problem with systemd service restart in case of nested mount namespaces without propagation from parent (with private mounts).
		+
		+	Nested mount namespace can have mount point with the same superblock, as the original mount point in parent mount namespace.
		+
		+	But after service restart it won't be like this anymore: mount point in master namespace will be changed, but not propagated to nested mount namespace. Moreover, mount point in nested mount namespace will become catatonic.
		+
		+	Thus, in case ot nested mount namespaces with disabled propagation one have to choose either:
		+	# Do not run the script, but keep all the mounts structure as it was (and broken systemd autofs services),
		+	# or use the script, but the price is catatonic autofs mounts in nested mount namespaces without propagation.

	[[Category:HOWTO]]		[[Category:HOWTO]]

@@ Line 11: / Line 11: @@
 CRIU supports both direct (offset) and indirect AutoFS mount points migration.
-Howewer, there is a limitation in migrating of systemd services, using AutoFS.
+However, there is a limitation in migrating of systemd services using AutoFS.
-The root of the limitation is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each AutoFS-related request from kernel side, and if they do not match - ignores the request.
+The root of the limitation is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each AutoFS-related request from kernel side, and if they do not match, it ignores the request.
 CRIU reconstructs AutoFS mount point on restore with different device ID, thus systemd doesn't recognize it anymore.
-In user world it means, that any access to AutoFS mount point, served by systemd, will hung. Restart of the service solves this issue.
+In user world it means that any access to AutoFS mount point served by systemd will stuck. Restart of the service solves this issue.
 == Tricks ==
-To overcome the limitation above, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
+To overcome the above limitation, <code>systemd-autofs-restart.sh</code> action script was introduced. It can be found in <code>scripts</code> directory in CRIU sources.
 This script is aimed to be used with CRIU option <code>--action-script</code> on restore to fix the issue for those systemd services, which can be painlessly restarted.
-Can be used something like below
+It can be used like this:
   criu restore ... --action-script /usr/libexec/criu/scripts/systemd-autofs-restart.sh
-It restarts only one service so far: <code>proc-sys-fs-binfmt_misc.automount</code>. But it can be easily extended to support any other.
+Currently, it only restarts one service, <code>proc-sys-fs-binfmt_misc.automount</code>. Surely, it can be easily extended to support any other.
 [[Category:HOWTO]]

@@ Line 3: / Line 3: @@
 == Requirements ==
-Autofs migration is supported by criu starting from version ...
+AutoFS migration is supported by CRIU starting from version ...
 Another requirement is linux kernel with version 4.6 or higher.
@@ Line 12: / Line 13: @@
 Howewer, there is a limitation in migrating of systemd services, using AutoFS.
-The problem is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each autofs-related request from kernel side.
+The root of the limitation is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each AutoFS-related request from kernel side, and if they do not match - ignores the request.
 [[Category:HOWTO]]

← Older revision		Revision as of 14:45, 22 April 2016
Line 1:		Line 1:
	If you have AutoFS mount inside the container, you need to know some tricks.		If you have AutoFS mount inside the container, you need to know some tricks.
		+
		+	== Requirements ==
		+
		+	Autofs migration is supported by criu starting from version ...
		+	Another requirement is linux kernel with version 4.6 or higher.
		+
		+	== Limitations ==
		+
		+	CRIU supports both direct (offset) and indirect AutoFS mount points migration.
		+
		+	Howewer, there is a limitation in migrating of systemd services, using AutoFS.
		+
		+	The problem is that systemd saves AutoFS mount point device ID in its internals and compares saved value with current one on each autofs-related request from kernel side.

	[[Category:HOWTO]]		[[Category:HOWTO]]