On Wed, 21 Oct 2015 11:12:31 +0200 "Ian D. Leroux" <[email protected]> wrote: > Tonight I'll try shutting down with various combinations of tmpfs > filesystems, to see if I can actually narrow down the problem to a > specific mount point.
As it turns out, I don't need shutdown to trigger the hang, umount is enough. Specifically, umount -f /dev Causes an immediate hang with the same kernel error message (..., on /var: file system full), attributed this time to the login command. (Without the -f, umount sensibly complains that /dev is busy). I can unmount /var/shm and /tmp (the other two tmpfs filesystems on this machine) without causing an immediate hang (but also without preventing a subsequent hang at shutdown time), so at least on my machine the problem seems to be specifically with unmounting /dev. The options as I currently see them are: - Unmounting /dev during shutdown (specifically during swap1_stop()) is expected to work. Then we have a problem with umount or perhaps with the exact timing of the call to umount. Maybe the hang has to do with unmounting a *busy* tmpfs filesystem? That would explain why I see this as a /dev-related problem (because /dev is the only tmpfs filesystem I have that is still busy at shutdown time) while others see a similar error without having a tmpfs /dev. - /dev should never be unmounted, and /dev is allowed to be on tmpfs. Then swap1_stop() should not forcibly unmount all tmpfs filesystems. Would it make sense to replace "umount -aft tmpfs" with "umount -at tmpfs", so as to remove only filesystems that aren't busy? - /dev is not allowed to be on tmpfs. Then I'm not seeing a bug, I'm just using a bogus configuration. Note, however, that the automatic creation of a tmpfs-mounted /dev is documented in init(8), and it's the only way I know of running with a read-only root partition. I'm out of time for tonight, but the next thing I want to try is to artificially make /tmp or /var/shm busy at unmount or shutdown time and see if I can trigger a hang that way. -- IDL
