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
