fsck seems to call readlink() on the target directory for the mounted check. This triggers the automounter, but if fsck itself is ran from the automounter context, the system will deadlock. It should avoid running anything else than lstat() on the target directory, which should not trigger the automount.
Can't fsck just look up the maj:min of the blockdev to check in /proc/self/mountinfo to determine if a blockdev is mounted?
Do you call fsck manually or from systemd? Does not have systemd enough information (as automount backend) to avoid this scenario? Why do you call fsck for the mountpoints? Maybe we can somehow detect that the target is managed by automount (statfs() and struct statfs->f_type ???).
(In reply to comment #2) > Do you call fsck manually or from systemd? The automounter, in this case systemd, calls it. > Does not have systemd enough information (as automount backend) to > avoid this scenario? Why do you call fsck for the mountpoints? It can not really avoid that, and it shouldn't. It's not about having information or not. fsck gets passed a block device only, and it has really not much business in readlink()ing mountpoints at that time, it should avoid that. > Maybe we can somehow detect that the target is managed by automount > (statfs() and struct statfs->f_type ???). Could be, not sure if that triggers the mount too, and I think it's still too fragile. The only allowed operation on random mountpoints is probably lstat(), everything else will add fragile and needless things, which should likely be avoided. An lstat() with a dev_t match against the dev_t list in /proc/self/mountinfo should really be good enough.
The problem is that the current code (util-linux 2.22) uses libmount to detect mounted filesystems, the code in libmount compares fstab entries with mountinfo entries. This is probably overkill and incorrect (the device does not have to be specified in fstab) for fsck. Not sure if devno is the right way, because btrfs uses some random crazy maj:min in /proc/self/mountinfo files. Fortunately possible fallback solution is to use open(device, O_RDONLY | O_EXCL), on mounted devices it returns EBUSY. I'll improve libmount (to make it less aggressive if possible) and fsck to care about the device only rather and use so complex detection code like now. ... will be fixed in the final 2.22 release.
Fixed by upstream commit 7a4f98854283a5b98e76902b12685ad1999b2802, Fedora package will be fixed after upgrade to the final 2.22 release.
util-linux-2.22-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/util-linux-2.22-1.fc18
util-linux-2.22-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.