SUMMARY drkonqi-sentry-postman (6.0.0) keeps uploading something with full speed, severely disrupting other network traffic, e.g. youtube streaming. New drkonqi-sentry-postman instances keep reappearing in the process list. At this point many MiB of, to me, unknown data have been uploaded to somewhere. The uploads persist after a reboot. I've had a lot of kate crashes previously today. STEPS TO REPRODUCE 1. Produce lots of crashes of e.g. kate OBSERVED RESULT Network is congested and barely usable EXPECTED RESULT Uploading stops at some point and/or rate is limited. Uploading can be stopped by user. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.7.0 Kernel Version: 6.7.6-zen4-xanmod1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon Graphics
> Uploading stops at some point and/or rate is limited. It stops when it has uploaded all crashes. > Uploading can be stopped by user. systemctl --user stop drkonqi-sentry-postman.{path,service,timer}
Hi, Can confirm this bug. I don't have a beefy internet connection, and when it starts, it will basically never end until I reboot my computer, which is more than problematic. Stopping and disabling the related service did not work. It came back on its own after a day.
I agree that there should be a GUI to manage the crash report queue. The queued reports can be found at ~/.cache/drkonqi/sentry-envelopes/ and the sent items at ~/.cache/drkonqi/sentry-sent-envelopes/ and too clear the queue you can delete the former directory. Since at least on my machine those files are only around 100 kB I don't know if some throttling is really required. Unless maybe you have many of them or a really slow internet connection. It should be possible though to save bandwidth and send the data compressed according to https://develop.sentry.dev/sdk/overview/#request-compression It also looks like the current error handling behaviour could be improved. If I interpret the code correctly then it will try to send all queued files and if one can't be sent due to whatever reason it will keep it in the queue to be picked up by the next run. The files will stick around for 30 days which seems to be a bit excessive. I'd reduce that to 7 days or so and add some logic to avoid resending if the server rejects the payload. I think there are also some issues with the systemd units: The timer is configured to run OnCalendar=hourly which will wake it every hour at the full hour. That's not really an issue for the user but not optimal for the server since it can cause a thundering herd problem. I would change that to OnUnitActiveSec=1 hour RandomizedDelaySec=5 minutes The timer has ConditionPathExistsGlob set. I might be wrong but I think (judging from the output of systemctl --user status drkonqi-sentry-postman.timer) this is evaluated only on unit start time, not on each interval. Ie. when nothing is queued on Plasma session start (when the timer is started) this timer is never executed. Maybe this condition should just be dropped. Then the postman would be executed once per hour but should exit quickly since it doesn't find any files to process. And I think on logon the service is executed twice if any events are queued: Once because of the PartOf=graphical-session.target in the service file and once because the path unit will be triggered.
I got carried away and totally forgot what I originally wanted to ask: I wonder how big those files are and how many there are, could you paste the output of the following command please: ls -lh ~/.cache/drkonqi/sentry-envelopes/ ~/.cache/drkonqi/sentry-sent-envelopes/
Waiting on the info Malte asked for
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!