whoopsie-upload-all no longer has a default timeout of many minutes, so
it will not wait for all reports to be uploaded. Subsequently, this
seems less important.
** Changed in: apport (Ubuntu)
Importance: High => Medium
** Changed in: apport (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1319477
Title:
whoopsie-upload-all waits for crash files to upload that have failed
to upload
Status in “apport” package in Ubuntu:
Triaged
Bug description:
whoopise logs information about failed uploads to syslog e.g.:
May 14 09:40:52 ubuntu-phablet whoopsie[1665]: Parsing
/var/crash/_usr_bin_whoopsie-preferences.0.crash.
May 14 09:40:52 ubuntu-phablet whoopsie[1665]: Uploading
/var/crash/_usr_bin_whoopsie-preferences.0.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</h1>#012No server is available to handle this
request.#012</body></html>#012
May 14 09:41:13 ubuntu-phablet whoopsie[1665]: Could not upload; processing
later (/var/crash/_usr_bin_whoopsie-preferences.0.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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1319477/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
