Re: runaway packagekitd process, was F29 Beta 1.5 problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 9/22/18 12:32 PM, Chris Murphy wrote:
On Sat, Sep 22, 2018 at 7:49 AM pmkellly@xxxxxxxxxxxx
<pmkellly@xxxxxxxxxxxx> wrote:

I decided to go ahead to try doing some testing. The runaway mode was
still running when I started testing things. First I did the desktop
browser tests and they passed. Then I did the desktop terminal tests and
they also passed. Then I ran the desktop update graphical tests using
the Software application. The application started fine and I could get
to the Updates screen okay, but when I clicked the Refresh button, after
a few seconds I got a gray colored pop up that said it could not
continue and a long list of errors. The pop up does not support Copy so
I didn't capture the details. I closed the Software application and
tried to reopen it. The window came up but the usual graphics and text
was not present. I restarted the PC to get out of the runaway mode and
then I was able to run the update graphical test to completion and it
passed.

It seems that this gnome-software runaway mode does more than just use
up cycles. I am discontinuing testing. Please let me know if there is
something more you want me to do / try.

I see a lot of these in your journal:

Sep 22 10:03:40 f29h.local packagekitd[1104]: g_object_ref: assertion
'G_IS_OBJECT (object)' failed

I see them in mine as well, no idea if they're related to the runaway
process. What I'm seeing is packagekit using about 9% CPU when it's
downloading metadata (refreshing repo and app info); and using a more
than 100% CPU when it's downloading files.

So I filed this:
g_object_ref spewing in journal bug
https://bugzilla.redhat.com/show_bug.cgi?id=1631968

It's probably a gtk thing but I've set the component to packagekit
since it's the one doing the spewing.

Also, you can disable the background downloading of updated packages
by packagekit with:

$ gsettings set org.gnome.software download-updates false

This is a per user setting. You still get metadata refresh, you can
still use Gnome Software to install/remove and update applications, it
just won't download any packages in the background, and so you also
won't get any notifications for updates. You can either use Gnome
Software or dnf to manually apply updates.



Thanks for filing the bug. I wasn't sure of what was going on. I'm not really familiar with the functions of packagekit. There is also the fact that the journal command Adam asked me to use was (sudo journalctl -b -u packagekit); so I guess I would expect most of the entries to be for packagekit. I am familiar with that setting. there is also:

gsettings set org.gnome.software allow-updates false

That one will stop retrieval of the meta data. I use them both on my "in use machines" because I always use dnf to get updates with (dnf upgrade --refresh). I left this Beta RC1.5 on my test machine in its as installed state since I intended to run the QA test cases on it.

According to the gnome system monitor application, it's gnome-software that's taking up all the cycles. gnome-software is another mystery to me. From the name it sounds like a library of functions common to lots of gnome applications.

As you saw in the note I posted that you responded to, I started doing some tests. Testing ran into a problem with the graphical updates test, but after a Restart to stop the runaway. I got Software to run the Refresh and the updates were installed. curiously, since then, the runaway has not started again. I'm going to leave it over night to see what happens. I just ran (dnf history info). Lots and lots of things, but notably, from my limited experience: kernel 4.18.9, gjs, glibc, gemu, curl, libcurl, and ostree. Is there some thing(s) I should check the history list for just in case tomorrow morning the runaway has not come back and perhaps make an estimate as to what the problem source was?

Thanks again for helping and Have a Great Evening!

	Pat (Tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux