On 8/18/19 1:26 AM, Laurent Bercot wrote: >> Sorry if I read this thread too hastily, but why not just keep /proc etc >> mounted, as was seemingly the way with s6-linux-init <=v0.4.x.x (and >> therefore slew)? Since the asymmetry is by nature, simply respecting it >> appears to be one minimalist way. > > The umount command basically performs a "umount -a". I can add a list > of filesystems that should be kept, but it's more ad-hoc code. It's > ugly. > But I guess the whole situation is ad-hoc anyway, so elegance isn't > exactly what we're going for here :/
Simply excluding filesystems doesn't help when the root filesystem is on one of these devices that needs teardown actions after being unmounted. In that case, the only workable solution is to have PID1 pivot_root() to a tmpfs with the teardown/reboot tools in it. That way you can actually fully unmount the former root filesystem. Under the current architecture, I think it is ideal to maintain the mount/unmount symmetry as much as possible. This is done in your service manager via dependencies. Have a oneshot for each filesystem that needs to be mounted, and (when applicable) have that oneshot depend on another oneshot that creates/destroys the underlying lvm/md/dm-crypt device. Then the dm device will be created before mount, and destroyed after unmount. Yes, unmounting will fail if the filesystem is in use (or already unmounted), and destroying will fail if the filesystem is still mounted, but that's okay because a `down` script should be idempotent and /always/ return success. Even when there are failures, this will minimize the number of loose ends left when shutdownd takes over. The unmounting done by shutdownd should be treated as a last resort. As a side note: what if there was a oneshot that did `kill -1` when brought down, and this oneshot depended on all of your filesystem mounts? Other than the obvious problem of s6-rc-update nuking your system, would it be possible to make s6-rc recover from being nuked and continue a shutdown? --Samuel
