Description of problem: Current status is: $ uptime 23:40:19 up 4 days, 4:42, 1 user, load average: 0,36, 0,42, 0,57 yet: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1577 root 20 0 1073368 434596 17800 S 0,0 3,6 0:32.10 /usr/libexec/packagekitd 1989 mrl 20 0 2017828 322332 57916 S 4,3 2,7 249:21.72 /usr/bin/gnome-shell This is sorted by the biggest memory users in my system. I don't like but I can understand gnome-shell using that much but seems packagekit is just using too much memory. I'm using F24, updated from a F23. Version-Release number of selected component (if applicable): PackageKit-1.1.1-3.fc24.x86_64 How reproducible: No idea, just noticed this. Steps to Reproduce: 1.Don't know 2. 3. Actual results: High memory usage Expected results: Normal memory usage Additional info: I'll keep it running as is in case you need some info from it.
Created attachment 1177841 [details] /proc/../smaps $ grep 'Rss.*[0-9]\{5,9\} ' smaps Rss: 47984 kB Rss: 63376 kB Rss: 65020 kB Rss: 65364 kB Rss: 13748 kB Rss: 65472 kB Rss: 22224 kB Rss: 40792 kB Rss: 55796 kB
Created attachment 1177842 [details] /proc/.../maps
Could you run packagekitd under valgrind please for a few days and see what it reports? Something like, dnf debuginfo-install PackageKit killall packagekitd valgrind --log-file=/tmp/packagekitd-valgrind-log --leak-check=full /usr/libexec/packagekitd
This is how it was now, before restarting: root 1577 0.0 3.5 1030508 427796 ? Ssl Jul04 1:51 /usr/libexec/packagekitd It didn't grow anymore since bug report. So I did a simple restart, just to check how it comes back: root 20289 1.5 0.1 533464 18684 ? Ssl 13:40 0:00 /usr/libexec/packagekitd Now it's running under valgrind as you requested, lets see. root 20388 37.2 0.9 465944 109328 pts/1 Sl+ 13:40 0:07 valgrind --log-file=/tmp/packagekitd-valgrind-log --leak-check=full /usr/libexec/packagekitd
I have the same problem. Memory usage seems to rise each time packagekitd checks for updates. After a few days without restarting you have a few hundred megabytes. Also downloading and installing updates seems to be much slower than using dnf on a command line.
(In reply to andylembke from comment #5) > I have the same problem. Memory usage seems to rise each time packagekitd > checks for updates. After a few days without restarting you have a few > hundred megabytes. > Also downloading and installing updates seems to be much slower than using > dnf on a command line. I'm on a fresh Fedora 24 installation btw.
Created attachment 1179752 [details] valgrind output It already looked like: root 20388 0.0 1.9 620380 233160 pts/1 Sl+ Jul11 3:30 valgrind --log-file=/tmp/packagekitd-valgrind-log --leak-check=full /usr/libexec/packagekitd it doubled. Valgrind output has some unresolved symbols but I have the debuginfos installed. Interesting that valgrind actually say they memory is still reachable?? THe leaks are minors and the 'still reachable' ones are quite comparable to the memory usage.
I spent some time today valgrinding packagekitd and fixed a number of leaks; hopefully this makes the situation a bit better. https://github.com/hughsie/PackageKit/commit/7e88a183f45cc6ebf77bf9387929580c457f010a https://github.com/hughsie/PackageKit/commit/812323cd1dcb241644d912b3b4d6e23816482f77 https://github.com/hughsie/PackageKit/commit/996f118e131028ac67f5fdba604706636f491477 https://github.com/hughsie/PackageKit/commit/fbc6388ef1560e482ef5fcbc47de4a04fa22d35f https://github.com/hughsie/PackageKit/commit/9e340cab85a736ca48e461e12e60d41f5b038a48 https://github.com/hughsie/PackageKit/commit/e056fac0ad108692c3b1ca16811d8ed6e7f09c5c https://github.com/hughsie/PackageKit/commit/a09cd3581967dfcd6fe8ffae5a6f04d998775fe9 https://github.com/rpm-software-management/libhif/pull/176
Cool, thanks. If you want I can give them a try if you prepare a package, btw.
Sure, http://koji.fedoraproject.org/koji/taskinfo?taskID=15204070 -- it's a master snapshot that uses new libdnf and has a bunch of other new code and may crash or not work properly in all cases. Testing very welcome :) Thanks!
Alright. Safety helmet if on, thanks for the advice. :) Pkgs are installed, root 25824 1.5 0.1 531632 18992 ? Ssl 13:49 0:00 /usr/libexec/packagekitd After hitting a command not found situation: root 25824 0.8 0.6 774988 77208 ? Ssl 13:49 0:01 /usr/libexec/packagekitd After hitting it again, it didn't change a thing. Now I'll leave it be for a while.
Now it looks like: root 1549 0.0 1.7 944628 208212 ? Ssl Aug11 0:14 /usr/libexec/packagekitd I didn't install any update. It checked, it warned be that there are updates, but I didn't do them.
root 1549 0.0 2.6 970336 312088 ? Ssl Aug11 0:33 /usr/libexec/packagekitd $ rpm -q PackageKit PackageKit-1.1.4-0.0.20160810.fc24.kalev10.x86_64 Laptop was suspended for most of the time during this weekend.
Yeah, looks like it's still slowly going up. I'll try to poke at this more when I get back from GUADEC.
$ ps aux | grep package root 23764 0.0 3.2 1068912 389416 ? Ssl Ago26 1:26 /usr/libexec/packagekitd $ uptime 09:22:41 up 11 days, 17:40, 1 user, load average: 0,26, 0,29, 0,41 But I had a reboot in between the reports, forgot to save the initial values.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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 using Fedora 25 a still facing common memory problem. After 3 days packagekitd proccess consumes 477.5 MB. uname -a: Linux localhost.localdomain 4.11.10-200.fc25.x86_64 #1 SMP Wed Jul 12 19:04:52 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Reopening. This doesn't seem to be fixed in F27. I just saw it take 800MB of RES for no apparent reason. In fact, I tend to go and kill it on a weekly basis as I see it often eating more and more memory over time.
/subscribe Packagekitd appears idle e.g. in pkmon, but it takes slightly more RAM than thunderbird. $ ps aux | grep package root 1445 0.0 4.5 1020784 362308 ? Ssl Feb07 0:46 /usr/libexec/packagekitd This was after 5 days. $ ls -ld /proc/$(pgrep ackag) dr-xr-xr-x. 9 root root 0 Feb 7 09:08 /proc/1445 $ date Mon 12 Feb 10:25:21 GMT 2018 After restarting (and exercising with pkcon refresh force + pkcon get-updates), the daemon process shows significantly smaller. $ ps aux | grep package root 22107 4.1 1.2 850696 102976 ? Ssl 10:28 0:04 /usr/libexec/packagekitd Though I'm still not madly happy to have 100M resident for an always-running daemon when idle. Swapping does not tend to go well! It seems a slightly surprising. When I think about the always-on part of packagekit, what comes to mind is the appdata metadata which was specifically created for packagekit. So you'd think it could use an specialized cache for this, which could be made efficient and/or be backed by disk files. Disk files *at least* get synchronized to disk more aggressively than process memory, which makes it less painful to page them out when someone else needs the RAM. I don't think we have a good reason to keep the distro-specific package manager loaded fully into RAM all the time.
Hello, It appears I'm having this bug as well, on two different machines with significantly differing hardware configurations. I've removed PackageKit for now, but I found it eating nearly 8GB of RAM idling on both machines. fpaste --sysinfo from one of them: https://paste.fedoraproject.org/paste/ps~emjYBjmQ64PnToih10Q Screenshot: https://photos.app.goo.gl/i1aYAxbiu4UKA7LQ6 As well, after some cursory reading, I'm wondering why PackageKit is running in the background at all; it is intentionally designed so that it does not run unless needed. Taken from https://www.freedesktop.org/software/PackageKit/pk-intro.html : Being system activated means that it's only being run when the user is using a text mode or graphical tool, and quits when it's no longer being used. This means we don't delay the boot sequence or session startup and don't consume memory when not being used. So just my 2¢, but I this should be fixed by making sure PackageKit is not running when not actively in use, and the memory leak fixes should come after.
There is a commit which fixes this issue in the official repo [0], but there has not been a new release since. For now, commenting out #ShutdownTimeout=300 in /etc/PackageKit/PackageKit.conf will shut down packagekitd after 5 minutes. Notice that #ShutdownTimeout=300 is also *not* the default used when the line is not commented out, the default was changed to 0 in an earlier commit mentioned in the commit message of commit [0] without updating PackageKit.conf accordingly. The commit message also mentions potential problems when using dnf or rpm alongside PackageKit when using a timeout. [0] https://github.com/hughsie/PackageKit/commit/0c84d71509e851db20445c747529bd7d3724f081
Sorry, I should have been more precise: The commit I mentioned dosen't fix a memory leak, but it does at least ensure that packagekit shuts down after a timeout by default. The memory leak might still be around anyway. (In reply to Volker Sobek from comment #22) > There is a commit which fixes this issue in the official repo [0], but there > has not been a new release since. > > For now, commenting out > > #ShutdownTimeout=300 > > in /etc/PackageKit/PackageKit.conf will shut down packagekitd after 5 > minutes. Notice that #ShutdownTimeout=300 is also *not* the default used > when the line is not commented out, the default was changed to 0 in an > earlier commit mentioned in the commit message of commit [0] without > updating PackageKit.conf accordingly. The commit message also mentions > potential problems when using dnf or rpm alongside PackageKit when using a > timeout. > > [0] > https://github.com/hughsie/PackageKit/commit/ > 0c84d71509e851db20445c747529bd7d3724f081
Just to tag in here, this bug appears to have gotten worse in F29. Like everyone else here has mentioned, I've seen this bug in previous versions but it always took a few days to build up and I have no real idea how to really help so I've not piled on. That being said, in the last two days of using F29, I've had packagekit climb to over ~300 MB in around 6 hours of usage without doing any installs or even opening software center. After the first day of seeing that I even made sure I disabled the new automatic updates options in Software Center, thinking that may help. Even more concerning though, is that today - after making sure I manually restarted the packagekit.service before puting the computer to sleep - the packagekit daemon grew from it's initial ~4MB (last I looked at it before going to sleep) to ~158MB (took a look as soon as I booted up). This happened, while the computer was supposed to be 'sleeping', locked and with the lid closed. I'd be happy to try to play guinea pig and test fixes to this if I can, but I may need some basic hand holding as I've never done it before.
I just wanted to add my voice as well, I see packagekitd taking up 600~800MB of RES within 2 days. As with Ryan, I would also be happy to test potential fixes.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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.
Richard, If you could, please update this to Fedora 29 as the problem appears to still exist.
(In reply to Scott Mattan from comment #28) > Richard, If you could, please update this to Fedora 29 as the problem > appears to still exist. I am not using PackageKit since then, btw. Scott, which package are you using?
packagekitd in F29 is automatically shutting down after a few minutes of inactivity. This should make sure that it doesn't start eating a lot of memory over time.
That's more a workaround than a fix. Can we really assume that it will have enough inactivity in all cases? Considering that the issue may lay on dependency handling, wouldn't it use less memory on its iterations by fixing this?
Yes, agreed that it's a workaround, but that's the best we can do when underlying libraries leak.
If we know which library it is, we can move the bug to it too.
(In reply to Marcelo Ricardo Leitner from comment #29) > (In reply to Scott Mattan from comment #28) > > Richard, If you could, please update this to Fedora 29 as the problem > > appears to still exist. > > I am not using PackageKit since then, btw. > > Scott, which package are you using? Richard, I apologize, seems I have Fedora 28 installed on this machine. It is running PackageKit-1.1.10-1.fc28.x86_64 That being said, I think Ryan from comment #24 posted that he was using Fedora 29 with the same issue.
workaround with ShutdownTimeout in '/etc/PackageKit/PackageKit.conf' doesn't help, Fedora 29. packagekit is leaking memory and sometimes is killed by OOM. PackageKit-1.1.12-2.fc29.x86_64
What does "CLOSED CURRENTRELEASE" mean? I still have the problem in Fedora 32. The memory use just keeps growing. After a few days, packagekitd is up to over 10GB (even after dnf remove -y plasma-pk-updates).
(In reply to poikilos from comment #36) > What does "CLOSED CURRENTRELEASE" mean? I still have the problem in Fedora > 32. The memory use just keeps growing. After a few days, packagekitd is up > to over 10GB (even after dnf remove -y plasma-pk-updates). PackageKit.x86_64 1.1.13-3.fc32 @updates PackageKit-Qt5.x86_64 1.0.1-5.fc32 @fedora PackageKit-command-not-found.x86_64 1.1.13-3.fc32 @updates PackageKit-glib.x86_64 1.1.13-3.fc32 @updates PackageKit-gstreamer-plugin.x86_64 1.1.13-3.fc32 @updates PackageKit-gtk3-module.x86_64 1.1.13-3.fc32 @updates
> What does "CLOSED CURRENTRELEASE" mean? It means that because nobody babysat this bz and bumped the version every 6 months, the automated bug tracker system decided the bug was out of date. Personally, it is the #1 reason I no longer submit bug reports for Fedora; it's a slap in the face to see a bug you worked on get closed because of "inactivity". Assuming the same bugs don't exist because it's a new release is asinine.
Fedora 32, uptime 3 days, sleeping while sitting on 400MB of RAM. I think Comment 38 is important: >> What does "CLOSED CURRENTRELEASE" mean? > It means that because nobody babysat this bz and bumped the version every 6 months, the automated bug tracker system decided the bug was out of date. Personally, it is the #1 reason I no longer submit bug reports for Fedora; it's a slap in the face to see a bug you worked on get closed because of "inactivity". Assuming the same bugs don't exist because it's a new release is asinine.
(In reply to Trae Santiago from comment #38) > > What does "CLOSED CURRENTRELEASE" mean? > > It means that because nobody babysat this bz and bumped the version every 6 > months, the automated bug tracker system decided the bug was out of date. > Personally, it is the #1 reason I no longer submit bug reports for Fedora; > it's a slap in the face to see a bug you worked on get closed because of > "inactivity". Assuming the same bugs don't exist because it's a new release > is asinine. No, it does not. An automatically closed bug is WONTFIX. This one has been _explicitly_ closed by the maintainer in comment 30, because packagekit implemented a workaround. Now, maybe that stopped working, but then that would be a _new_ bug, even if the visible problem is the same.
High memory usage still happens on Fedora 33 after the hibernation of the laptop. $ ps vax --sort=-rss | head -n 2 PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 3937 ? Ssl 8:54 4634 0 1894340 1359280 8.3 /usr/libexec/packagekitd $ free total used free shared buff/cache available Mem: 16257248 4947620 3385904 1246756 7923724 9646168 Swap: 12394488 781568 11612920 $ lsb_release -d Description: Fedora release 33 (Thirty Three) $ uname -svrp Linux 5.11.7-200.fc33.x86_64 #1 SMP Wed Mar 17 18:55:20 UTC 2021 x86_64 What information can I find and attach to help to fix this problem?
This issue is still present and I refuse to open a new bz, because the issue was never fixed nor properly understood. So I'm just reopening it. I did a fresh F34 install and there is packagekit again: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7032 root 20 0 1484628 781316 24824 S 0,0 2,4 1:18.59 packagekitd 306339 mrl 20 0 4316388 552604 248608 R 7,0 1,7 0:44.07 firefox $ uptime 17:37:41 up 5 days, 23:29, 12 users, load average: 0,98, 0,98, 0,87 $ rpm -qf /usr/libexec/packagekitd PackageKit-1.2.4-2.fc34.x86_64
I'm still seeing the issue on Fedora 33 ps vax --sort=-rss | head -n 2 PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 141972 ? Ssl 1:13 22906 0 1274280 692800 2.8 /usr/libexec/packagekitd rpm -qf /usr/libexec/packagekitd PackageKit-1.2.2-2.fc33.x86_64 uptime 03:47:48 up 5 days, 14:27, 1 user, load average: 2.60, 3.59, 4.47 This isn't too bad as I've recently rebooted, but I often go a couple of weeks between reboots
There seem to be a problem still in fc34: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9238 root 20 0 1969640 1,4g 6868 S 0,0 4,6 9:14.85 /usr/libexec/packagekitd % rpm -qa PackageKit PackageKit-1.2.4-2.fc34.x86_64 % uptime 10:50:46 up 19 days, 17:08, 17 users, load average: 1,95, 4,88, 16,11 Cannot be normal with 1.4g RSS use for a simple daemon??
Confirmed still present on Fedora 35 ❯ ps vax --sort=-rss | head -n 2 PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 2365 ? Ssl 1:57 323 0 1835924 1360040 2.0 /usr/libexec/packagekitd ❯ rpm -qa PackageKit PackageKit-1.2.4-3.fc35.x86_64 ❯ uptime 20:04:19 up 4 days, 7:47, 3 users, load average: 0,49, 0,83, 0,76
Confirmed still present on Fedora 36 Beta. I did use the workaround to set a ShutdownTimeout in '/etc/PackageKit/PackageKit.conf', and that mitigates the consequences of the bug for me.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I just noticed packagekitd on Fedora 35 is using lots of memory on my system - it's resident set size is almost 1Gb! This is after being up for 12 days. I restarted it and its RSS is now 244 M (not sure what units htop uses). I can't believe this bug has been open for 6 years now.
> it's resident set size is almost 1Gb PackageKit the daemon actually does very little. If you look at the heap with something like massif then it's going to be 99.99% libdnf allocating RSS.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 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. Thank you for reporting this bug and we are sorry it could not be fixed.
Sigh.
Or maybe we should consider opening a Fedora Changeset entry to drop this unmaintained package (PackageKit). 6 years already of a large memory leak and nobody cares to fix it.
Well, yes. Sorry, reassigning back to PackageKit, as that's where the bug is perceivably. Maybe the underlying case is in libdnf, but it currently doesn't manifest outside PackageKit so that's where the issue will need to be investigated. On dnf we currently have other priorities. Anyone is welcome to pick this up and find where the issue is (or report a libdnf-only reproducer).
Just bumped into this issue on Fedora 36. With uptime of 18 min packagekitd now is consuming 477M (RES) on my machine. It looks like too much for me.
confirmed still present on f37. ps vax --sort=-rss|head -n2;rpm -qf /usr/libexec/packagekitd;uptime PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 2263 ? Ssl 248:42 967 0 20727092 16698124 33.8 /usr/libexec/packagekitd PackageKit-1.2.5-2.fc37.x86_64 17:03:59 up 24 days, 19:00, 11 users, load average: 2.54, 6.47, 11.44
Created attachment 1935026 [details] smaps from packagekitd process
Created attachment 1935027 [details] maps from packagekitd process
after restart packagekitd is, well, using a lot less memory: ps v $(pgrep packagekitd) PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 3971253 ? Ssl 0:04 25 0 646840 137888 0.2 /usr/libexec/packagekitd
Still happening on Fedora 36. I often go several weeks between reboots, with the RSS climbing to multiple GB. # ps v $(pgrep packagekitd) PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 5402 ? Ssl 1:22 86 169 1322678 724948 2.2 /usr/libexec/packagekitd # rpm -qa PackageKit PackageKit-1.2.5-1.fc36.x86_64 # uptime 11:17:51 up 1 day, 17:33, 6 users, load average: 1.41, 1.52, 1.62 Even after a service restart it idles at ~160M # systemctl restart packagekit # ps v $(pgrep packagekitd) PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 850897 ? Ssl 0:02 15 169 636806 164684 0.5 /usr/libexec/packagekitd
On Fedora 37 it goes above 300Mb soon after startup, even with all the updates were installed right before the reboot: [papa@t102ha ~]$ ps v $(pgrep packagekitd) PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 1105 ? Ssl 1:02 85 0 1015284 345732 9.0 /usr/libexec/packa
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still an issue on Fedora 37, and is obviously never going to get fixed. Why isn't this package just removed from the next Fedora release? Or has that already happened? I thought I needed this in the past - I've been upgrading my existing install for years now, I assume it was used by KDE or Gnome at some point. I tried a dnf remove PackageKit just now on Fedora 37 and no other packages of note require it - mainly KDE.
(In reply to Patrick Mansfield from comment #63) > This is still an issue on Fedora 37, and is obviously never going to get > fixed. It was actually fixed in Fedora 38 (released in April), where packagekitd now shuts down on idle.
Thanks Gordon. Finally.