36
edits
Changes
Jump to navigation
Jump to search
Line 11:
Line 11: − However, there is a limitation in migrating of systemd services using AutoFS.+ + − + + − 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.+ + + + + + + + +
→Limitations
CRIU supports both direct (offset) and indirect AutoFS mount points migration.
CRIU supports both direct (offset) and indirect AutoFS mount points migration.
But CRIU reconstructs AutoFS mount point on restore with different device ID and root inode number.
This leads to some limitations in migrating of 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.
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.
In user world it means that any access to such an AutoFS mount point will stuck.
Known Autofs masters:
# <code>systemd</code>: AutoFS-based services
::Systemd saves AutoFS mount point device ID in its internals.
::Restart of the service solves this issue.
# <code>automount</code>: Direct (offset) mounts
::Automount saves AutoFS mount point device ID and root inode number for direct (offset) monuts in its internals.
::Killing automount with SIGKILL and restarting it solves this issue.
== Tricks ==
== Tricks ==