| Summary: | `abrt-cli rm ...` can print "Can't remove directory '...': Directory not empty" in some cases | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Hutař <jhutar> |
| Component: | abrt | Assignee: | abrt <abrt-devel-list> |
| Status: | CLOSED WORKSFORME | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | abrt-devel-list, jakub, jberan, michal.toman, mkutlak, mkyral, mmarusak, msuchy |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-18 12:36:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. We are not going to fix this in EL6. We may consider this in upstream. This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. It is filed against very old abrt-cli-2.0.8-16 (current is abrt-cli-2.11.1-3) and was no able to reproduce this. (I am aware it is kinda timing-related, but I tried my best). I am closing it as possibly fixed, but if anyone is able to reproduce it, please reopen with the reproducer. |
Description of problem: Under some circumstances `abrt-cli rm ...` do not deletes given report. Looks like this happens when given directory is still being generated. Version-Release number of selected component (if applicable): abrt-cli-2.0.8-16.el6_4.1.x86_64 How reproducible: rarely Steps to Reproduce: 1. # sleep 1000 & # in mine case I had some crash generated in background # this is probably not a correct reproducer, but reflects # what I have seen 2. # kill -s SEGV $! 3. # abrt-cli list \ | sed -n 's/^Directory:\s\+//p' \ | xargs -r -n 1 abrt-cli rm -- Actual results: With correct timing this might happen: # abrt-cli list \ | sed -n 's/^Directory:\s\+//p' \ | xargs -r -n 1 abrt-cli rm -- rm '/var/spool/abrt/pyhook-2013-10-08-12:40:17-1338' rm '/var/spool/abrt/pyhook-2013-10-08-12:39:48-497' Can't remove directory '/var/spool/abrt/pyhook-2013-10-08-12:39:42-800/dell-pesc430-01-2013100812391381250396/etc': Directory not empty Can't remove '/var/spool/abrt/pyhook-2013-10-08-12:39:42-800/dell-pesc430-01-2013100812391381250396/etc': Directory not empty Can't remove '/var/spool/abrt/pyhook-2013-10-08-12:39:42-800/dell-pesc430-01-2013100812391381250396': Directory not empty # abrt-cli list @0 Directory: /var/spool/abrt/pyhook-2013-10-08-12:39:42-800 executable: /usr/share/rhn/up2date_client/hardware.py package: rhn-client-tools-1.0.0.1-8.el6 time: Tue 08 Oct 2013 12:39:42 PM EDT uid: 0 Expected results: No errors should be printed - they should not be just hidden, but `abrt-cli rm ...` should not got to this situation. Additional info: I do understand this do not guarantee me all the reports are deleted (as some other might be generated during this action), but at least should not print errors.