On 2009-05-19 at 02:15:03, the file system containing the processed crash dumps ran out of inodes. From that time until about 07:17:00 the same day, all 33986 newly submitted crashes failed processing. While we've never done it before, we can resubmit these crashes for reprocessing. The storage system used to store the failed crashes is exactly the same format as the queue for processing new crashes. Reprocessing them is as simple as copying the failed file system tree (as specified by the 'saveFailedMinidumpsTo' configuration parameter for monitor.py) into the queued file system tree (the 'storageRoot' configuration parameter). Monitor should be paused during the copy of the file system tree. The only disadvantage is that many crashes that failed processing for reasons other than this disk problem will also be resubmitted for processing. This disadvantage is really pretty minor. The question is: "Are these 33986 important enough to warrant the time and effort?"
I don't care about those few reports, for statistical reasons anyway.
without the need for the crashes, we need not worry about resubmission
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.