36
edits
Changes
Jump to navigation
Jump to search
Line 30:
Line 30: + + + + + + + + + + + + + + + + + + + + + +
no edit summary
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]]