Hello, Whilst investigating an issue related to an unresponsive NFS server and 'find' process which hung, we observe this stack trace from strace -k:
$ strace -k ./find /srv -name apple ... openat(AT_FDCWD, ".", O_RDONLY|O_CLOEXEC) = 3 > /usr/lib64/libc-2.33.so(open+0x5b) [0xf0fcb] > /tmp/findutils-4.10.0/find/find(open_safer+0x17) [0x412f37] > /tmp/findutils-4.10.0/find/find(save_cwd+0x1c) [0x42d3bc] > /tmp/findutils-4.10.0/find/find(record_initial_cwd+0x1d) [0x409b2d] > /tmp/findutils-4.10.0/find/find(main+0x24) [0x4039f4] > /usr/lib64/libc-2.33.so(__libc_start_main+0xd4) [0x27b74] > /tmp/findutils-4.10.0/find/find(_start+0x2d) [0x403b8d] ... This is surprising because the starting-point argv is an absolute path on a local filesystem, not affected by potential NFS problems. find appears to hang due to the openat(AT_FDCWD, ".", ...). I appreciate there are workarounds to choose a better cwd before calling find, but for this search with no -exec actions, is record_initial_cwd / cleanup_initial_cwd necessary? Cheers, Phil
