Re: runaway packagekitd process, was F29 Beta 1.5 problem
On 9/23/18 1:16 PM, Chris Murphy wrote: I would keep testing other things, and try to break it, and file bugs or report it on test@ if you're confused about some behavior. On Sun, Sep 23, 2018 at 6:29 AM, pmkel...@frontier.com wrote: On 9/22/18 12:32 PM, Chris Murphy wrote: On Sat, Sep 22, 2018 at 7:49 AM pmkel...@frontier.com 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. In regard to the update: As I wrote yesterday, after a restart to stop the runaway. the Update Graphical test was run with Software successfully and the updates were installed. I also used dnf to look at the history and listed some of the changed / replaced packages. Well, there had not been a recurrence of the runaway from when the updates were run to when I wrote last yesterday. After that the machine set logged in, but locked for the rest of the day and overnight. The runaway has not recurred. Since it always recurred within such a period, I am guessing that one of the updates fixed the problem. I should have noted yesterday that neither packagekit nor gnome-software were among the package names seen in the history list yesterday. Any ideas? I will continue leaving the machine idle with no changes, updates, or testing until I hear back on what, if anything, I should do next. Have a Great Day! Pat (tablepc) I ran the non-coconut test cases with no failures with the exception of keyring. I don't use that and am not familiar with how to use it so I always skip that one since I don't want to generate false failures. I observed no failures or anomalies while running the test cases. Then I decided to configure the machine to be like my in use machines. First I ran the software uninstalls and installs script. After I ran the software script and did a restart, I started getting three SELinux alerts that I never got before. So far, these occur only when I do a restart and are 100% repeatable. process=boltd, acc=create, dir=power process=boltd, acc=add_name, dir=power process=boltd, acc=write, dir=boltd I have never seen this before and I have no idea if this is a bug or purely the result of software that was uninstalled, or software that got installed. Then I ran the settings script and it ran fine with no additional problems noted. I just started dead or alive testing the applications with no additional problems found so far. The gnome-software runaway has not repeated. I was there was a update for gnome-shell so I ran that. After the restart I still got the same SELinux alerts. Weather is one of the applications I uninstall. I thought maybe in this version that libgweather was uninstalled too. That library seems to be used lots of places and I thought if it was gone that might be the root of the SELinux alerts, but I looked and libgweather is still installed. I also tried turning off all of the gnome-shell extensions that get installed. I
Re: runaway packagekitd process, was F29 Beta 1.5 problem
On 9/22/18 12:32 PM, Chris Murphy wrote: On Sat, Sep 22, 2018 at 7:49 AM pmkel...@frontier.com 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@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: runaway packagekitd process, was F29 Beta 1.5 problem
On Sat, 2018-09-22 at 10:32 -0600, Chris Murphy wrote: > On Sat, Sep 22, 2018 at 7:49 AM pmkel...@frontier.com > 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 Thanks for that. I found what looks like a fix for it upstream, and also noticed quite a lot of other bugfix commits ahead of the current Fedora build, so I've backported a bunch of those and am running a new PackageKit build now: https://koji.fedoraproject.org/koji/taskinfo?taskID=29813351 once that's done I'll submit an update. Please give that updated PackageKit a shot and see if it behaves better. Thanks! (CCing hughsie to let him know what I did) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: runaway packagekitd process, was F29 Beta 1.5 problem
On Sat, Sep 22, 2018 at 7:49 AM pmkel...@frontier.com 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. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: F29 Beta 1.5 problem
On Fri, 2018-09-21 at 08:49 -0400, pmkel...@frontier.com wrote: > Yesterday afternoon (9/20), I did a clean install of F29 Beta 1.5 onto > bare metal via DVD. The PC is a Lenovo M59P with an E8400 processor. The > ISO had been check-summed and passed. The PC booted fine and the media > test ran and passed. Anaconda ran perfectly and the install completed > normally. I did a restart, logged in, and allowed the lock to time out. > > The fan on this system rarely runs at all, but in a few hours of sitting > idle the fan came on. I logged in and started the system monitor and > noted the both core0 and core1 were trading off running at 100%. The > trade cycle was running between 20 and 30 seconds. Sometimes they would > both run at 50% for a few seconds. When I looked at the processes, > gnome-software was the problem. I let the lock time out and left the > system overnight. This morning (9/21) the fan was running full speed and > both core0 and core1 was stuck hard at 100%. Again gnome-software was > the problem. I wanted to see if anything else would run so I started > Rhythm box. There were delays getting it going, but it did start and > worked (radio stream) with no apparent gaps in the audio. When I checked > the Resources and processes, apparently gnome-software was sharing with > Rhythm Box, but only what Rhythm Box needed. When I closed Rhythm Box, > gnome-software went back to taking 90+% of the core0 and core1 cycles. > > I just did a restart and the system returned to normal (fan not > running). This time I'm not going to login. I'm just going to let it sit > and see what happens. > > This is the same problem I found a few days ago with B 1.3 I wrote about > it then, but it was a day later, after a reminder that I wrote and > called out gnome-software. mschwendt reported much the same in the thread "Neverending CPU usage by gnome-software and packagekit". I wonder if software/pk is getting stuck somehow, or doing something far more often than it should. Can one of you post the output of 'sudo journalctl -b -u packagekit', perhaps? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
F29 Beta 1.5 problem
Yesterday afternoon (9/20), I did a clean install of F29 Beta 1.5 onto bare metal via DVD. The PC is a Lenovo M59P with an E8400 processor. The ISO had been check-summed and passed. The PC booted fine and the media test ran and passed. Anaconda ran perfectly and the install completed normally. I did a restart, logged in, and allowed the lock to time out. The fan on this system rarely runs at all, but in a few hours of sitting idle the fan came on. I logged in and started the system monitor and noted the both core0 and core1 were trading off running at 100%. The trade cycle was running between 20 and 30 seconds. Sometimes they would both run at 50% for a few seconds. When I looked at the processes, gnome-software was the problem. I let the lock time out and left the system overnight. This morning (9/21) the fan was running full speed and both core0 and core1 was stuck hard at 100%. Again gnome-software was the problem. I wanted to see if anything else would run so I started Rhythm box. There were delays getting it going, but it did start and worked (radio stream) with no apparent gaps in the audio. When I checked the Resources and processes, apparently gnome-software was sharing with Rhythm Box, but only what Rhythm Box needed. When I closed Rhythm Box, gnome-software went back to taking 90+% of the core0 and core1 cycles. I just did a restart and the system returned to normal (fan not running). This time I'm not going to login. I'm just going to let it sit and see what happens. This is the same problem I found a few days ago with B 1.3 I wrote about it then, but it was a day later, after a reminder that I wrote and called out gnome-software. Have a Great Day! Pat ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
