Fedora 37: PackageKitd using 100% CPU

Ask Fedora
1

Problem

PackageKitd is using 100% CPU for a long time, but does not seem to be doing anything useful.

Cause

Not yet known.

Related Issues

Bugzilla report: #NNNN

Workarounds

Restarting packagekit service fixes the problem for the moment.

2

Hi @jorgegv , welcome to the community.

It may have got “stuck”. You can restart it and that usually fixes it:

sudo systemctl restart packagekit.service

You can also force refresh your cache, and that sometimes helps too:

pkcon refresh force
1 Like
3

Yes, I already said that in my original topic (restarting the service is the workaround).

Question is: it should not get stuck, so this is probably a bug. It has happened to me at least twice in the first 24 hours from upgrading, so clearly there is some issue with PackageKit in F37.

I’ll open a bug next time it happens, with some traces.

1 Like
4

I’m seeing this as well on Fedora 37 (recently upgraded from 36). Looks like there is some logic that is continually retrying and logging out:

...
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447696_cddbedad scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447696_cddbedad from uid 1000 finished with need-untrusted after 84ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447697_ddcbddba scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447697_ddcbddba from uid 1000 finished with need-untrusted after 82ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447698_dcabeccd scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447698_dcabeccd from uid 1000 finished with need-untrusted after 81ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447699_cacbceec scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447699_cacbceec from uid 1000 finished with need-untrusted after 83ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447700_aedddbdd scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447700_aedddbdd from uid 1000 finished with need-untrusted after 83ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447701_cbeeacad scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447701_cbeeacad from uid 1000 finished with need-untrusted after 83ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447702_aeadecde scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447702_aeadecde from uid 1000 finished with need-untrusted after 83ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447703_cbecddbd scheduled from uid 1000
Jan 10 09:27:37 felian PackageKit[1870]: update-packages transaction /447703_cbecddbd from uid 1000 finished with need-untrusted after 83ms
Jan 10 09:27:37 felian PackageKit[1870]: new update-packages transaction /447704_aadceeab scheduled from uid 1000
...

I’m able to restart the service to “fix” it.

I do have some versionlocks, not sure if relevant:

$ sudo dnf versionlock list
xorg-x11-drv-nvidia-cuda-libs-3:520.56.06-1.fc37.*
kmod-nvidia-6.0.15-300.fc37.x86_64-3:520.56.06-1.fc37.*
xorg-x11-drv-nvidia-kmodsrc-3:520.56.06-1.fc37.*
xorg-x11-drv-nvidia-3:520.56.06-1.fc37.*
akmod-nvidia-3:520.56.06-1.fc37.*
xorg-x11-drv-nvidia-libs-3:520.56.06-1.fc37.*
nvidia-settings-3:520.56.06-1.fc37.*
nvidia-persistenced-3:520.56.06-1.fc37.*
nvidia-gpu-firmware-0:20221214-145.fc37.*
xorg-x11-drv-nvidia-cuda-3:520.56.06-1.fc37.*
xorg-x11-drv-nvidia-power-3:520.56.06-1.fc37.*

I’m able to semi-reliably replicate this issue.

5

Unless you have a very specific reason to need the nvidia drivers locked at that version it seems better to update to the newer version (525.60.11-1.fc37 at present). Newer versions of both firmware and drivers are developed to support newer hardware as well as to improve performance on existing hardware.

Having the kmod-nvidia package locked there may even be preventing using a newer kernel with the nvidia drivers since the kmod-nvidia package is automatically built locally by akmods and akmod-nvidia when a kernel or driver is updated.

I also do not know if this may or may not be related to the packagekit issue.

6

The latest drivers were working on Fedora 36, but unfortunately I had a very frustrating few hours trying to get them working with Fedora 37 before I gave up and locked to the specific versions (about 1 week ago). Is this forum and appropriate place to get “real-time” support for Nvidia GPU driver issues? (Happy to engage in other avenues of communication if more appropriate.)

7

On fedora there is a lot of support here for the nvidia drivers.

We could work on it if you were to post the following as preformatted text using the </> button above.
inxi -Fzxx
dnf list installed '*nvidia*'

Since that is an nvidia issue and not a packagekit issue please open a new topic for that.

1 Like
8

I have this issue about once a week, no version locked packages but I wonder if there is some issue with an unsigned or wrongly signed package (logs are very similar to Devin’s.

Additionally the pkcon refresh force command suggested by @ankursinha asks about installing unsigned software and failes when denied. (-v didn’t help unfortunately)

I always use dnf for package management, I think that means I never use packagekitd.

[dar@cdf ~]$ pkcon refresh force
Refreshing cache              [=========================]         
Waiting for authentication    [=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
[... some repetition of the previous two lines ...] 
Loading cache                 [=========================]         
Finished                      [                         ] (0%)  
Do you want to allow installing of unsigned software? [N/y] n

The unsigned software will not be installed.
                              [=========================]         
Fatal error: user declined interaction
1 Like
9

I just saw the same issue with the same type of log entries as @devinrsmith. For the moment I just systemctl mask’ed packagekit.service and packagekit-offline-update.service. Heavy-handed, I know, but there doesn’t seem to be any other permanent fix available right now.