whoopsie-upload-all waits for crash files to upload that have failed to upload
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Expired
|
Medium
|
Unassigned |
Bug Description
whoopise logs information about failed uploads to syslog e.g.:
May 14 09:40:52 ubuntu-phablet whoopsie[1665]: Parsing /var/crash/
May 14 09:40:52 ubuntu-phablet whoopsie[1665]: Uploading /var/crash/
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: Sent; server replied with: No error
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: Response code: 503
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: Server replied with:
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: <html><body><h1>503 Service Unavailable<
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: Could not upload; processing later (/var/crash/
Here the report was uploaded but the core dump upload failed. whoopsie does not write a .uploaded files in this case and whoopsie-upload-all waits the full timeout period of 1800s although whoopsie is not making any further attempts to upload that core dump and there are no others to process. This seems inefficient.
Changed in apport (Ubuntu): | |
importance: | Undecided → High |
whoopsie should create a flag file indicating whether or not is online or offline. In the event that whoopsie receives a 503 when trying to upload the core dump then the state should change to offline or a new flag file regarding the ability to upload the coredump. This should appear in /run/whoopsie or /run/lock.