>There are certain setups that require doing something after
>filesystems are unmounted. Two examples are LVM logical volumes and
>LUKS encrypted volumes, but I suppose there must be more cases. In any
>such setup, the shutdown sequence would include a 'vgchange -a n'
>command or 'cryptsetup close' command after filesystems are unmounted.
Ah, of course it had to be more complex... Sigh.
There are two ways to proceed here:
- If a filesystem can track all the processes that have a handle on
it, it is possible to have it be mounted/unmounted symmetrically by
the service manager. At unmount time, kill the processes that would
block the unmount operation, then perform the unmount, then run the
additional commands. In that case it's all done at the service manager
level, s6-linux-init doesn't have to do anything.
- There could be a hook in the autogenerated stage 4 script, which
runs a user-provider script, something like rc.shutdown.after-umount.
I don't much like giving control to a user script at that level, when
there are no services running and no mounted filesystems, possibly
not even /proc or /sys, and when a hang in a user script could
very well prevent a clean reboot; but it's the best I can do.
Admins/distros would have to make sure the deactivate_* functions
only call binaries that are on the root filesystem.
Thoughts?
The asymmetry of mounting and unmounting filesystems is really a pain
in the ass for the design of an init/shutdown sequence. I wanted to
keep the shutdown as quick, minimal, and reliable as possible, but it
seems there's no way to do so with those snowflake filesystems. :/
--
Laurent
Received on Sat Aug 17 2019 - 23:01:35 UTC