I can't figure out how this started just logged in and saw the CPU pinned: 5998 root 20 0 711560 99560 16152 S 99.0 0.4 1242:56 packagekitd PackageKit-1.1.10-1.fc28.x86_64 4.16.9-300.fc28.x86_64 Seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=1483066 gdb packagekitd 5998 GNU gdb (GDB) Fedora 8.1-15.fc28 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... packagekitd: No such file or directory. Attaching to process 5998 [New LWP 5999] [New LWP 6000] [New LWP 6650] [New LWP 7264] warning: .dynamic section for "/lib64/librpmio.so.8" is not at the expected address (wrong library or version mismatch?) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f4148a8240c in pthread_setcanceltype (type=603979808, oldtype=0x80) at forward.c:200 200 FORWARD (pthread_setcanceltype, (int type, int *oldtype), (type, oldtype), 0)
Started happening to me when I upgraded to Fedora 29 (beta). It looks like it's constantly refreshing the repos. Seeing lots of messages like this in the logs: Oct 05 10:39:34 dima-dell packagekitd[30354]: Skipping refresh of Dropbox: cannot update repo 'Dropbox': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: S> Oct 05 10:39:41 dima-dell PackageKit[30354]: update-packages transaction /15922_bdececce from uid 1000 finished with success after 9112ms Oct 05 10:39:41 dima-dell PackageKit[30354]: get-update-detail transaction /15923_edebcace from uid 1000 finished with success after 27ms Oct 05 10:39:41 dima-dell PackageKit[30354]: get-updates transaction /15924_daedcaad from uid 1000 finished with success after 195ms Oct 05 10:39:43 dima-dell packagekitd[30354]: Skipping refresh of Dropbox: cannot update repo 'Dropbox': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: S> Oct 05 10:39:46 dima-dell PackageKit[30354]: get-updates transaction /15925_eeaaceae from uid 1000 finished with success after 4869ms Oct 05 10:39:46 dima-dell PackageKit[30354]: new update-packages transaction /15927_ecaeceae scheduled from uid 1000 Oct 05 10:39:46 dima-dell PackageKit[30354]: get-updates transaction /15926_abbeaebe from uid 1000 finished with success after 205ms Oct 05 10:39:48 dima-dell packagekitd[30354]: Skipping refresh of Dropbox: cannot update repo 'Dropbox': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: S> Oct 05 10:39:55 dima-dell PackageKit[30354]: update-packages transaction /15927_ecaeceae from uid 1000 finished with success after 8787ms Oct 05 10:39:55 dima-dell PackageKit[30354]: get-update-detail transaction /15928_bacedeed from uid 1000 finished with success after 29ms Oct 05 10:39:55 dima-dell PackageKit[30354]: get-updates transaction /15929_edacdaab from uid 1000 finished with success after 180ms
Also, looks like it stopped doing it after I manually ran "sudo dnf update --refresh".
I just noticed the same behaviour. packagekitd keep one CPU at 100% and all the RAM in the system. Debugging this even over ssh is a pain. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19042 root 20 0 26,6g 23,8g 15828 S 92,7 75,9 3329:42 packagekitd 3377 kp 20 0 6261848 138268 33616 S 6,0 0,4 118:54.91 gnome-shell Browsing through the log I notice that the logs are fine until Nov 1'st: Oct 31 06:03:22 zen.local systemd[1]: Starting PackageKit Daemon... Oct 31 06:03:22 zen.local systemd[1]: Started PackageKit Daemon. Oct 31 06:05:00 zen.local PackageKit[16581]: get-updates transaction /4422_aedcecba from uid 1000 finished with success after 98473ms [...] Oct 31 06:10:17 zen.local PackageKit[16581]: daemon quit Then the day after: Nov 01 06:03:24 zen.local systemd[1]: Starting PackageKit Daemon... Nov 01 06:03:24 zen.local PackageKit[19042]: daemon start Nov 01 06:03:24 zen.local systemd[1]: Started PackageKit Daemon. Nov 01 06:04:18 zen.local PackageKit[19042]: get-updates transaction /4436_cbaadcca from uid 1000 finished with success after 53904ms [...] But this time it never stops... (3 days running :/) # du -h /var/log/journal/ 2,1G /var/log/journal/ (!) Trying to stop packagekit: # systemctl stop packagekit.service just hang...
I've seen the same issue on Fedora 28 multiple times, too. Packagekitd would: - use up 100% CPU - allocate all available RAM (over time) Usually I recognize it only when the responsiveness of the whole system is getting worse. At that time it is already too late for lots of debugging, I'm glad to get packagekitd killed. Most time it happens when packagekitd seems to upgrade its own database in the background. Today the issue (at least 100% CPU problem) happened during a "dnf update" which caused the update to fail and the rpm database to be corrupted.
I confirm the problem on Fedora 29: packagekitd uses 100% CPU for a couple of minutes since I logged in. It does it every time I start or reboot the system. See also the discussion here: https://bugs.launchpad.net/appcenter/+bug/1587975 Some say it's related to third party repository and/or missing GPG keys. But they are using Ubuntu/Elementary OS... I'll try to investigate and debug my system.
After a system upgrade, this doesn't occur anymore. packagekitd pops up for a few seconds at startup and uses only 50% of CPU. Before the upgrade I was able to reproduce the 100% CPU issue every time and it lasted for minutes. In `journalctl -xe` I see a few errors related to PackageKit or gnome-software: dic 23 16:04:07 fedora packagekitd[1292]: Skipping refresh of cygn-pulseaudio-dlna: Failed to download gpg key for repo 'cygn-pulseaudio-dlna': Curl error (28): Timeout was reached for https://copr-be.cloud.fed> and a couple of: dic 23 16:04:12 fedora gnome-software[2159]: ignoring non-installed app GsApp: [0x7fbe7c18e280] The first in particular seems to match the comments on Launchpad issue. cygn-pulseaudio-dlna is a Copr repo which I disabled some time ago. I have no package installed from there at the moment. Why is packagekitd trying to download the gpg key of a disabled repository? It cannot find it because it's cropping the URL, as it assumed that URL can have only one subdomain: https://copr-be.cloud.fedoraproject.org became https://copr-be.cloud.fed this repo has the following link: gpgkey=https://copr-be.cloud.fedoraproject.org/results/cygn/pulseaudio-dlna/pubkey.gpg
I've reported the URL issue upstream: https://github.com/hughsie/PackageKit/issues/304
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Hello, I am running Fedora 36 and encountering pretty much the same exact issues as described in this thread. packagekitd is pinning my CPU and using up increasing amounts of memory. I cannot kill it using systemctl. Journalctl is showing me some errors which are in the pastebin here: https://paste.centos.org/view/910ebb33
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days