Created attachment 787477 [details] A tarball of the requested folder Description of problem: As requested by Jakub in bug 953927: > 2. The second and the third columns are empty on the last line and it means > that uuid file resp. duphas file is not accessible. But uuid file must > always be present in problem directory, otherwise local duplicates search > doesn't work. Could you please check that > /var/tmp/abrt/ccpp-2013-08-10-01:04:28-1168/uuid exists? If not, please file > a new bug and attach the directory. $ ls /var/tmp/abrt/ccpp-2013-08-10-01:04:28-1168/uuid ls: cannot access /var/tmp/abrt/ccpp-2013-08-10-01:04:28-1168/uuid: No such file or directory Version-Release number of selected component (if applicable): abrt-2.1.6-3.fc19.x86_64
Thank you for taking the time to help us with improving ABRT. The problem you attached has been detected while computer was shutting down and ABRT had no time to process it in standard way and produce all necessary files. It is not possible to process these problems on next boot because computer's state may have changed. ABRT should not notify the incomplete problems at all. It is probably safe to delete the incomplete problems and provide a configuration option which would make preserving them in the dump location.
(In reply to Jakub Filak from comment #1) > Thank you for taking the time to help us with improving ABRT. The problem > you attached has been detected while computer was shutting down and ABRT had > no time to process it in standard way and produce all necessary files. Shouldn't ABRT inhibit the shutdown of the computer until it has finished processing? Or at least, completely give up and not keep trace of the problem, so it doesn't annoy users at next boot? > ABRT should not notify the incomplete problems at all. It is probably safe > to delete the incomplete problems You mean I should remove them from the filesystem myself? > and provide a configuration option which > would make preserving them in the dump location. So originally you asked me to open this bug report because my ~/.cache/abrt/ignored_problems contained like this: /var/tmp/abrt/ccpp-2013-08-04-02:02:38-4377;; I.e they were missing the UUID. If a report is incomplete (e.g it doesn't have that uuid file), then maybe ABRT should ignore it completely, not notify me about it, and not add that incomplete line to the ignored_problems file?
(In reply to Mathieu Bridon from comment #2) > (In reply to Jakub Filak from comment #1) > > Thank you for taking the time to help us with improving ABRT. The problem > > you attached has been detected while computer was shutting down and ABRT had > > no time to process it in standard way and produce all necessary files. > > Shouldn't ABRT inhibit the shutdown of the computer until it has finished > processing? > Good point! This could be optional. > Or at least, completely give up and not keep trace of the problem, so it > doesn't annoy users at next boot? > Oh, I'm sorry. The second paragraph is a note for us. As you said, ABRT should delete all incomplete problems at next boot and not annoy users. > > ABRT should not notify the incomplete problems at all. It is probably safe > > to delete the incomplete problems > > You mean I should remove them from the filesystem myself? > Only if you want to clean your disk space, otherwise it is not necessary to remove the problem data. However, if you don't want to report the problem manually, the data are useless. > > and provide a configuration option which > > would make preserving them in the dump location. > > So originally you asked me to open this bug report because my > ~/.cache/abrt/ignored_problems contained like this: > > /var/tmp/abrt/ccpp-2013-08-04-02:02:38-4377;; > > I.e they were missing the UUID. If a report is incomplete (e.g it doesn't > have that uuid file), then maybe ABRT should ignore it completely, not > notify me about it, and not add that incomplete line to the ignored_problems > file? Yes, exactly. Thank you!
The upstream commit cf34c6beb62b324e4dac22624b0e0ed56084af3f fixes this bug.
abrt-2.1.10-1.fc19,libreport-2.1.10-1.fc19,satyr-0.12-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/abrt-2.1.10-1.fc19,libreport-2.1.10-1.fc19,satyr-0.12-1.fc19
Package abrt-2.1.10-1.fc19, libreport-2.1.10-1.fc19, satyr-0.12-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.1.10-1.fc19 libreport-2.1.10-1.fc19 satyr-0.12-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23304/abrt-2.1.10-1.fc19,libreport-2.1.10-1.fc19,satyr-0.12-1.fc19 then log in and leave karma (feedback).
abrt-2.1.10-1.fc19, libreport-2.1.10-1.fc19, satyr-0.12-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.