Description of problem: packagekitd is spewing hundreds of lines (dozens per second) Sep 22 10:00:29 f29h.local packagekitd[1104]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Version-Release number of selected component (if applicable): PackageKit-1.1.10-4.fc29.x86_64 PackageKit-gtk3-module-1.1.10-4.fc29.x86_64 gtk2-2.24.32-3.fc29.x86_64 gtk3-3.24.1-1.fc29.x86_64 How reproducible: Appears to happen when refreshing metadata, it's not continuous. Seems like the bigger the update, exponentially more of these messages appear Steps to Reproduce: 1. boot, wait a while, look in the journal 2. 3. Actual results: packagekitd mad/confused, and it's using > 100% CPU but I don't know if the two are related; it's definitely a lot of repetitive spew in the journal. Expected results: Additional info:
Created attachment 1486016 [details] journal
Wondering if https://github.com/hughsie/PackageKit/pull/278 was possibly related to this? I can't quite tell just from the diff.
Aha, no, it looks like it was this: https://github.com/hughsie/PackageKit/commit/5a74b6c81964893709c5f5620ee78ed73725634e
PackageKit-1.1.10-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c9e62ae82
I was deliberately holding off putting this fix in F29. I'll have to unpush the update, otherwise things break when https://github.com/rpm-software-management/libdnf/pull/589 lands.
can't we just make sure this is switched back again when that lands? I sent this because people are complaining about the flood of errors, and it seems at least possible it's causing significant CPU usage...
I guess so. I didn't want to have a case where updating libdnf would break packagekit, but maybe that's not really much of an issue if we can get new packagekit in before, or together with new libdnf. In any case, we are going to do a new packagekit release next week to get all the libdnf compat fixes out. I was waiting with the release just to sort this one fix out properly first :)
"I didn't want to have a case where updating libdnf would break packagekit, but maybe that's not really much of an issue if we can get new packagekit in before, or together with new libdnf." That's what I'm saying, yeah. Since Bodhi is on now, we have control over this: all it takes is ensuring we do a PackageKit -6 (which we'll kinda have to do anyway now this build *exists*, even if it's unpushed) and include it in the update along with NM. If you're planning to get all this done on Monday of course we may as well forget about this update, but if it's gonna take longer than that, maybe we can push it out again. I mean, heck, we can just submit it, and if it's still in testing when the new libdnf and NM are done, we can just edit it and put those builds in instead. I'm a provenpackager, so I have the powers. Just whatever you do, *don't* submit separate updates for the two, because once that happens, only bowlofeggs can fix it. :P
PackageKit-1.1.11-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c9e62ae82
Note, PackageKit 1.1.11 actually goes back to the old code here, and compared to 1.1.10-5 will *break* this...unless you also get libdnf 0.20. Unfortunately there are some problems with pulling libdnf 0.20 into F29 right away...
That's not true. It should work fine with both the libdnf version in stable and 0.20.0. It leaks a bit of memory with the stable version, but that should be fine since it now shuts down after 300 secs of idle and restarts on demand.
PackageKit-1.1.11-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.