Hi, On Arch Linux, various package install scripts use findmnt to check the status of /boot or /usr. However, if there exists a stale NFS mount on the system (for instance on /mnt), findmnt hangs when used in commands such as: findmnt -snero fstype --tab-file '/etc/fstab' -T '/usr' findmnt -s /boot findmnt -s /usr (note that on my system, /usr is not a mount point of any kind, while /boot is ext4. /mnt is the stale NFS mount) This older Arch bug https://bugs.archlinux.org/task/36629 refers to the problem, but as far as I can tell the problem still exists in the same form (at the time, the package maintainer added the -T option to the command "findmnt -snero fstype --tab-file '/etc/fstab' -T '/usr'", but I don't believe it changed anything). In any case, from having a look at the code on the latest git (I can reproduce the hang with 710ed55dcd), I believe the problem comes from the following sequence. When used with the -s|--fstab flag, findmnt goes through the list of mount points in the tab file, and compares them with the target specified, say '/usr'. The comparison is done using mnt_fs_match_target() in findmnt.c:match_func(). mnt_fs_match_target() uses mnt_resolve_path() on both target ('/usr') and fs->target, which uses canonicalize_path(fs->target), which uses realpath(fs->target). As the fs->target is the stale NFS mount point, this last call hangs in a lstat(). While it is clear that a system with a stale NFS mount point is a minefield, would it be possible to avoid the call to "realpath(fs->target)" (maybe controlled by a command line option)? As it is, it is impossible to upgrade an Arch Linux install when there is a stale NFS mount anywhere on the system (and listed in fstab). Thanks, Eric -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
