umount: add note about --lazy

Unfortunately, it's pretty common that users on production systems use
lazy umount to fix some FS issues. The usual result is unwanted system
reboot, because -l is not the right way how to fix unreachable NFS or
mess with local FS with submounts.

Note that after lazy umount /proc/self/mountinfo does not contain the
FS entry, but kernel still references the FS. It makes it very
difficult to debug.

Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1566674
Suggested-by:  Steve Dickson <steved@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/sys-utils/umount.8 b/sys-utils/umount.8
index 1e27f01f8957b0f3f6ef0d52a745807de1331dab..fb0601c6d121c548c54f184cf884d66a2a1d8245 100644 (file)
--- a/sys-utils/umount.8
+++ b/sys-utils/umount.8
@@ -55,7 +55,8 @@ working directory there, or when a swap file on it is in use.  The
 offending process could even be
 .B umount
 itself - it opens libc, and libc in its turn may open for example locale
-files.  A lazy unmount avoids this problem.
+files.  A lazy unmount avoids this problem, but it may introduce another
+issues. See \fB\-\-lazy\fR description bellow.
 .SH OPTIONS
 .TP
 .BR \-a , " \-\-all"
@@ -119,6 +120,13 @@ By default such a helper program is called if it exists.
 Lazy unmount.  Detach the filesystem from the file hierarchy now,
 and clean up all references to this filesystem as soon as it is not busy
 anymore.
+
+A system reboot would be expected in near future if you're going to use this
+option for network filesystem or local filesystem with submounts.  The
+recommended use-case for \fBumount -l\fR is to prevent hangs on shutdown due to
+an unreachable network share where a normal umount will hang due to a downed
+server or a network partition. Remounts of the share will not be possible.
+
 .TP
 .BR \-n , " \-\-no\-mtab"
 Unmount without writing in