Description of problem: find raises SIGABRT if it hits a currently-unmounted, autofs filesystem (e.g. created with a systemd automount unit) that is a bind mount back up into the directory tree being traversed. For instance, say we have /tmp/a a tmpfs filesystem, with /tmp/a/b an automounted bind mount back to /tmp/a: > systemctl cat tmp-a.mount # /etc/systemd/system/tmp-a.mount [Mount] What=tmpfs Where=/tmp/a Type=tmpfs > systemctl cat tmp-a-b.mount # /etc/systemd/system/tmp-a-b.mount [Mount] What=/tmp/a Where=/tmp/a/b Type=tmpfs Options=bind > systemctl cat tmp-a-b.automount # /etc/systemd/system/tmp-a-b.automount [Automount] Where=/tmp/a/b We start the mount point /tmp/a, but only the automount unit for /tmp/a/b: > systemctl start tmp-a.mount tmp-a-b.automount If find is then run on /tmp/a it crashes: > find /tmp/a /tmp/a /tmp/a/b /tmp/a/b/b Aborted (core dumped) I suspect that find is calling stat on /tmp/a/b (which *does not* mount the filesystem) before descending into it (which does mount it), and the directory's characteristics changing underneath it is confusing it. Version-Release number of selected component: findutils-4.5.12-7.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: find /tmp/a crash_function: leave_dir executable: /usr/bin/find kernel: 3.18.3-201.fc21.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (4 frames) #2 leave_dir at fts-cycle.c:136 #3 fts_read at fts.c:1096 #4 find at ftsfind.c:573 #5 process_all_startpoints at ftsfind.c:635
Created attachment 987371 [details] File: backtrace
Created attachment 987372 [details] File: cgroup
Created attachment 987373 [details] File: core_backtrace
Created attachment 987374 [details] File: dso_list
Created attachment 987375 [details] File: environ
Created attachment 987376 [details] File: limits
Created attachment 987377 [details] File: maps
Created attachment 987378 [details] File: open_fds
Created attachment 987379 [details] File: proc_pid_status
This must be a file system bug -- two distinct directories end up with the same dev/ino pair, which AFAIK should never happen: $ stat --printf "%d\t%i\t%n\n" /tmp/a{,/b{,/b,},} 16 1126487 /tmp/a 21 1142349 /tmp/a/b 16 1142347 /tmp/a/b/b 16 1126487 /tmp/a/b 16 1126487 /tmp/a
I would've thought any bind mount would do that. Whether or not that's the case, I'm sure that's not the problem here. With a regular (non-automounted) bind mount, find handles this situation correctly, reporting "File system loop detected" when descending into the bind mount. The problem only manifests itself if the bind mount is *added* while find is running. The automount is just a useful way to do this at exactly the right time to trigger the race condition. I strongly suspect that the bug could be hit by a well-timed mount(2) even in the absence of autofs.
(In reply to Michael Chapman from comment #11) > I would've thought any bind mount would do that. Indeed. I did not realize it was the bind mount what caused the problem.
I have proposed a patch upstream: http://article.gmane.org/gmane.comp.lib.gnulib.bugs/34867
fixed in findutils-4.5.14-3.fc23 and findutils-4.5.14-3.fc22
findutils-4.5.12-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/findutils-4.5.12-8.fc21
Package findutils-4.5.12-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing findutils-4.5.12-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-2177/findutils-4.5.12-8.fc21 then log in and leave karma (feedback).
findutils-4.5.12-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
upstream commit: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=60af6a36