Difference between revisions of "AutoFS"
Skinsbursky (talk | contribs) |
(Typos, punctuation, wording) |
||
| Line 11: | Line 11: | ||
CRIU supports both direct (offset) and indirect AutoFS mount points migration. | CRIU supports both direct (offset) and indirect AutoFS mount points migration. | ||
| − | + | 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 | + | 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. | CRIU reconstructs AutoFS mount point on restore with different device ID, thus systemd doesn't recognize it anymore. | ||
| − | In user world it means | + | 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 == | == Tricks == | ||
| − | To overcome the limitation | + | 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. | 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. | ||
| − | + | It can be used like this: | |
criu restore ... --action-script /usr/libexec/criu/scripts/systemd-autofs-restart.sh | criu restore ... --action-script /usr/libexec/criu/scripts/systemd-autofs-restart.sh | ||
| − | + | 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]] | [[Category:HOWTO]] | ||
Revision as of 16:01, 22 April 2016
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.
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, 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 stuck. Restart of the service solves this issue.
Tricks
To overcome the above limitation, systemd-autofs-restart.sh action script was introduced. It can be found in scripts directory in CRIU sources.
This script is aimed to be used with CRIU option --action-script on restore to fix the issue for those systemd services, which can be painlessly restarted.
It can be used like this:
criu restore ... --action-script /usr/libexec/criu/scripts/systemd-autofs-restart.sh
Currently, it only restarts one service, proc-sys-fs-binfmt_misc.automount. Surely, it can be easily extended to support any other.