Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionDaniel Reynolds
2023-08-16 05:20:11 UTC
Description of problem:
1. find is being used on NFS file systems.
2. two processes e.g. 'find DIR -name PATTERN -ignore_readdir_race -exec rm {} \;' look for files to delete in the same directory.
3. one archive process works as expected.
4. the other archive process running 'find' reports error message
'find: '/path/to/file': No such file or directory'
Note, only shows up on NFS file systems not local file systems.
Version-Release number of selected component (if applicable):
- findutils-4.6.0-20.el8.x86_64
How reproducible:
Sometimes
Steps to Reproduce:
1. Create two find processes deleting files as above.
2. Run many times, sometimes find reports error 'find: '/path/to/file': No such file or directory'
Actual results:
'find: '/path/to/file': No such file or directory'
Expected results:
With option -ignore_readdir_race find should ignore missing files when trying to stat() them.
Additional info:
- high business impact for customer. Blocking migration.
- strace performed confirming behaviour and attached to case. See extract below.
~~~
231057 18:30:01.360720 getdents64(4</infadata/Backup/FIND_POC/Target>, [{d_ino=154801, d_off=11878423, ... d_name="MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log"}] ...
231057 18:30:27.998095 newfstatat(5</infadata/Backup/FIND_POC/Target>, "MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log", 0x55dc79775fe8, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) <0.000327>
231057 18:30:27.999508 newfstatat(5</infadata/Backup/FIND_POC/Target>, "MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log", 0x7ffe36e02980, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) <0.000343>
231057 18:30:28.000927 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, "find: ", 6) = 6 <0.000416>
231057 18:30:28.002800 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, "\342\200\230/infadata/Backup/FIND_POC/Target/MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log\342\200\231", 100) = 100 <0.000506>
231057 18:30:28.004705 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, ": No such file or directory", 27) = 27 <0.000412>
[snip]
231057 18:30:30.384816 +++ exited with 1 +++
~~~
Hello!
Thank you for the report! I was able to reproduce this issue on my machine. This problem was already reported to upstream few years back (https://savannah.gnu.org/bugs/?45930) but the fix was not committed upstream, yet. So it is possible to encounter it on any release of RHEL or Fedora (even RHEL 7), it just happens that NFS on RHEL 8 has "better" timings to trigger it. Fortunately, the fix seems trivial.
I'll update you ASAP when I have additional information to share.
Regards,
Lukas
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (findutils bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:7179
Hi,
I have recently encounted this same issue on a RHEL7 system with find (GNU findutils) 4.5.11.
I didn't see a related errata or BZ for RHEL7, so I was wondering if it would need to be reported again, or if the same fix could be applied to RHEL7?
Hello Nathan,
this issue was only fixed in RHEL 8, 9 and Fedora. It was not fixed in RHEL 7 because that release was (and still is) in a maintenance mode only. If you would like to see this issue fixed in RHEL 7 and you have a reasonable justification for it, please raise a ticket through the Customer Portal first instead. Otherwise, I suggest to upgrade to a newer release of RHEL. Also, please use https://issues.redhat.com/ to file tickets in the future, RH Bugzilla is no longer used for RHEL products. Thank you!
Regards,
Lukas
Description of problem: 1. find is being used on NFS file systems. 2. two processes e.g. 'find DIR -name PATTERN -ignore_readdir_race -exec rm {} \;' look for files to delete in the same directory. 3. one archive process works as expected. 4. the other archive process running 'find' reports error message 'find: '/path/to/file': No such file or directory' Note, only shows up on NFS file systems not local file systems. Version-Release number of selected component (if applicable): - findutils-4.6.0-20.el8.x86_64 How reproducible: Sometimes Steps to Reproduce: 1. Create two find processes deleting files as above. 2. Run many times, sometimes find reports error 'find: '/path/to/file': No such file or directory' Actual results: 'find: '/path/to/file': No such file or directory' Expected results: With option -ignore_readdir_race find should ignore missing files when trying to stat() them. Additional info: - high business impact for customer. Blocking migration. - strace performed confirming behaviour and attached to case. See extract below. ~~~ 231057 18:30:01.360720 getdents64(4</infadata/Backup/FIND_POC/Target>, [{d_ino=154801, d_off=11878423, ... d_name="MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log"}] ... 231057 18:30:27.998095 newfstatat(5</infadata/Backup/FIND_POC/Target>, "MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log", 0x55dc79775fe8, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) <0.000327> 231057 18:30:27.999508 newfstatat(5</infadata/Backup/FIND_POC/Target>, "MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log", 0x7ffe36e02980, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) <0.000343> 231057 18:30:28.000927 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, "find: ", 6) = 6 <0.000416> 231057 18:30:28.002800 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, "\342\200\230/infadata/Backup/FIND_POC/Target/MC_EDH_SIDE_CAR_GCP_POST_VBUP20230730-02:18:29_SmLYdODCg7.log\342\200\231", 100) = 100 <0.000506> 231057 18:30:28.004705 write(2</infadata/Backup/FIND_POC/Log/find_and_remove_GLT0.log>, ": No such file or directory", 27) = 27 <0.000412> [snip] 231057 18:30:30.384816 +++ exited with 1 +++ ~~~