Bug 752564

Hi,

I've explicitly set 'interval=86400' in section [CheckUpdate] (change Check for updates to Hourly (Apply) and change back to Daily (Apply) and everything seems fine. When Check for updates is set to Hourly I still have the five minutes cycle as mentioned on the kde-fedora mailing list.

Martin Kho

kde-settings-4.7-14.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kde-settings-4.7-14.fc16

Package kde-settings-4.7-14.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-settings-4.7-14.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16215/kde-settings-4.7-14.fc16
then log in and leave karma (feedback).

Hi,

Weird! Yesterday I updated kde-settings to the above version and removed the [CheckUpdate] section from ~/kde/share/config/apper. Now the '5 minutes cycle' is back :-(

So globally setting these defaults has no effect?

or

did I have to log out/reboot?

Sorry,

Martin Kho

Btw. There seems to be more at the door. Suddenly akonadi_imap_resource crashed with a segmentation fault, but that's an other story. Never seen this before. Time for a reboot. I think. :-)

I would definitely suggest restarting your session to properly test this, yes.

Hi Rex,

It's running (or sleeping :-)) now for a few hours. Anything seems fine. Tomorrow I'll let you know (after a check happened) if everything is still okay.

Martin Kho

Btw. Should I open another report for the 'hourly' slippery?

Hi,

After 24+ hours I've not seen any problems with the default settings (check Daily). So this issue seems to be solved.

Thanks,

Martin Kho

If "hourly" is still every 5 minutes, there's still a bug. An hour has 60 minutes around here. ;-) (Well, 45 at the university. ;-) But definitely not 5…)

Hi,

It looks like that the "Daily" issue isn't also solved yet :-( Today the 5 minutes cycle is back again. What did I do? Nothing special. Last night I did - in konsole - run the command "yum list *kopete*". Further I had open: Dolphin, KMail2, Chrome (G+) and Firefox (G-search). So it seems to be a rather complicated issue.

Sorry,

Martin Kho

.. and in the systemtray are sitting: besides the default apps, kopete, amarok, and wuala (online storage)


Martin Kho

kde-settings-4.7-14.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Nope, still doing it here; yumBackend.py taking up 100% of a CPU core every five minutes, regular as clockwork.  I tried running a "yum clean all" and "yum check-update" manually in case it was a corrupted package DB, but that didn't change a thing.

Also, for some bizarre reason, it appears to be mucking around with my DPMS settings when it kicks in and again while it's running.  I can run "xset s dpms 0 0 0 -dpms", wait for the CPU to spike then when I run "xset q" it reports times of 48/72/96 and DPMS enabled.  I've tried resetting the settings while it's running and it looks like it resets them at least once more before it exits as well.

Since this is a media centre PC, this is something of a showstopper for me - kind of hard to enjoy a film when you have to twitch the cursor every minute or so... :(

This bug is _not_ fixed. After checking for updates in apper in the most recent version available for F16, yumBackend.py will wake up every 5-10 minutes and use 100% CPU the entire time. Why this bug was closed I don't know, it should be re-opened.

Removing apper rpm solves the problem; it appears that the issue is with apper-sentinel.

I wouldn't mind checking every 5 minutes if this did not use 100% of cpu
for a minute or so.
For now I've disabled it.
I thought this was fixed when I updated to kernel 3.1.6-1 but now
I've updated to 3.1.7-1 and it seems to have reappeared.

Hi,

FYI (This is NOT a solution, but a workaround!!):

The issue seems to happen/start somewhere in the apper daemon (Apper Monitor in System Settings -> Startup and Shutdown -> Service Manager) (polling method?).

When apper 'gets wild' it goes to 'normal operation' after you've stopped the daemon, wait a while (> 5 minutes) and have started it again. At least this 'works' for me.

Hope this help.

Martin Kho

This seems to help for me:

echo "
[CheckUpdate]
checkUpdatesOnBattery=false
checkUpdatesOnMobile=false
installUpdatesOnBattery=false
installUpdatesOnMobile=false
interval=86400" >> $HOME/.kde/share/config/apper

Same bug confirmed (every 5 minutes, 100% one 1 CPU) on "Linux 3.1.8-2.fc16.x86_64 #1 SMP Sat Jan 7 13:35:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux"

System is up-to-date.

Just updated to 3.1.9-1.fc16.x86_64 and the problem is back.
I finally did this to stop it
 mv /usr/share/PackageKit/helpers/yum/yumBackend.py  /usr/share/PackageKit/helpers/yum/yumBackend.pyxxx

Previously I tried the $HOME/.kde/share/config/apper update above and thought it had solved the problem.

This bug looks like a duplicate of:
https://bugzilla.redhat.com/show_bug.cgi?id=748790

Though I suspect "100% load" and "every 5 minutes" are really two separate bugs - fewer people might notice the "active every 5 minutes"  part if not for the 100% cpu load.

Most likely the 5 minute check is the rather overzealous apper default (kde bug?).
The 100% bug is purely a Yum bug.

- Gilboa

I think the problem is Apper doesn't write its all configuration options into the file: ~/.kde/share/config/apper. Even if you change some options other than the interval the "interval=" line is not appended. I changed the default interval (Daily), saved options, changed the setting back and finally saved changes again. However, this didn't prevent yumBackend.py from running. I had to log out and in. Now, it seems like it is OK.

So, should the config file be generated with all the options set properly, the problem whould't occur. In the meantime one has to do by hand.

Hi,

The just pushed update for apper (0.7.1-0.7.20120218.fc16) (See bug #749240 [1]) seems to solve this issue too. At least it looks promising. I'v set the check interval to hourly and had no ~5 to 10 minutes wakeups. Maybe the following change [2] did the trick:

-    if (sender()) {
+    if (qobject_cast<PkTransaction*>(sender())) {
         // if we have a sender this method was caller by PkTransaction
+        // be carefull because QSignalMapper from KDialog also calls this method

Hope this 'nasty' issue will also solved. :-)


Martin Kho

[1] https://bugzilla.redhat.com/show_bug.cgi?id=749240
[2]http://quickgit.kde.org/index.php?p=apper.git&a=commitdiff&h=8e43cddd2634b03ee5a05f5287792bb006e903f8 in file /Sentinel/SessionTask.cpp

... and yes it still checks for updates. :-)

Martin Kho

Hi,

Maw, I was too optimistic ;-( After the first check follows the next one after ~5 minutes. Sorry.

Martin Kho

I can confirm this bug on a fully updated Fedora 16 i686 install.  Frustration finally caused me to simply remove apper.

Bobby

The problem still persists (fully updated Fedora 16 x64)

I confirm the bug on Fedora 16 x64. extremely frustrating when it kills the battery of your laptop.

Linux version 3.3.0-8.fc16.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) ) #1 SMP Thu Mar 29 18:37:19 UTC 2012


apper-0.7.1-1.fc16.x86_64

So, while the bad news is that this issue is still a mystery, the good news is that bug #748790 is finally getting addressed, which means that at least the excessive checks won't be that taxing on your battery anymore.

That said, I'd love seeing a fix for this one too!

Hi,

R. Hughes says: "In other words, pkcon refresh now spends just about 20 s CPU time instead of 8 minutes."

Can it be that apper is triggered twice in the 'old' (8 minutes) situation. It uses a 5 minutes timeout. So with the shortening of the pkcon refresh period the apper wake ups will be gone too?

Martin Kho

quite possible, we'll have to continue testing after bug #748790 is fixed

Hi,

No, the fix for bug #748790 doesn't fix the wake ups, at lease for me :-(. The only difference is that the refresh is really fast now. And that's certainly good news.

So there have to be something else that is still wrong.

Sorry,

Martin Kho

Hi,

I've looked (again) into the Apper daemon code (ApperD) and there is something I can't get clear. In this code 'm_lastRefreshCache' plays  a crusial role in the Refresh and Update cicle, correct?
Code from apperd.cpp:
"if (m_lastRefreshCache.isNull() || m_lastRefreshCache.toTime_t() < maxTime) {
            callApperSentinel(QLatin1String("RefreshAndUpdate"));"

In two places 'm_lastRefreshCache' gets a (new) value:

1) --> ApperD::ApperD(...)
if (!m_sentinelIsRunning && nameHasOwner(QLatin1String("org.freedesktop.PackageKit"), QDBusConnection::systemBus())) {
        ...
        m_lastRefreshCache = getTimeSinceRefreshCache();
}

2) --> ApperD::Poll()
if (m_lastRefreshCache.isNull()) {
        ...
        m_lastRefreshCache = getTimeSinceRefreshCache();
}

Now imagine the following scenario:
A refresh and update just happened because m_lastRefreshCache.toTime_t() < maxTime) was true. After five minutes m_lastRefreshCache is not Null and apper-sentinel isn't running and/or org.freedesktop.PackageKit has no owner. 
My question is: In this scenario how get m_lastRefreshCache updated? Is this scenario plausable?

Thanks,

Martin Kho

Martin Kho

Hi,

I got to the scenario in comment 34, because I killed both apper-sentinel and packagekitd (checked qdbus --system to see if org.freedesktop.PackageKit still existed) and found that the wake up were still there.

Martin Kho

Created attachment 577327 [details]
[patch] to keep Apperd from waking up packagekitd

Hi,

BEWARE USE ON YOUR ONW RISK!!! 

I've no idea what the side effects are with this patch. Till now I've not seen any wake ups. But have to test it much longer. May be someone who has real programming skills and more inside information into Apper's internals can say  more about the sanity of this patch.

Martin Kho

Created attachment 577834 [details]
[patch] Apperd is doing now what it has to do...

... apperd has to (according to the source code):

1. Refresh the package cache periodicaly (based on the refresh interval set in the configuration file);
2. Update or Display Package Updates;
3. Display Distro Upgrades;
4. Start Sentinel to keep an eye on running transactions.

Point one was especially a problem. The first patch was sub-optimal. There was still one extra call to update the cache. I found that it takes a while before the refresh-cache value is settled after a refresh (and update) call. This brought me to the current patch.

Now apper is doing the following:
a. at start up (mostly at login): cache refresh and update and after five minutes an update call (not cache refresh).

b. running: (I've set the update interval to hourly) every hour the cache is refreshed and updates are checked.

So for me this issue is 'solved'. May be a programmer can look into the patch to see if nothing really nasty is happening.

Thanks and I hope this helps,

Martin Kho

In the meantime, mind giving apper-0.7.1-2 from koji a try?

Hi Rex,

My patch is essentially doing the same, to make sure the next cycle the new refresh-cache value will be read. So please forget my patch. It seems indeed solved with apper-0.7.1-2. I'll test it thourougly.

Thanks,

Martin Kho

apper-0.7.1-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/apper-0.7.1-2.fc17

apper-0.7.1-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/apper-0.7.1-2.fc16

Hi,

Everything works fine now. When others have confirmed that 0.7.1-2 is working for them, please close this report.

Thanks for the really nice work!

Martin Kho

Thank you, Martin, for the excellent detective work! :)

Dannti (usptream dev) informed us this is not yet a complete fix, so stay tuned.

Hi,

I see after every Refresh and Update six minutes later an Update request. This is still not good?

@Lukáš Tinkl: you're welkom :-)

Martin Kho

Package apper-0.7.1-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing apper-0.7.1-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6029/apper-0.7.1-2.fc16
then log in and leave karma (feedback).

Hi,

It took me a while to find the debug information from Apper. In kdebugdialog I had to enable kded ... of course :-). Now I see in .xsession-errors the following messages:

kded(1385) ApperD::callApperSentinel: "RefreshAndUpdate"
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" "" ":1.119"
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 0
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" ":1.119" ""
kded(1385) ApperD::callApperSentinel: "Update"
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" "" ":1.121"
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 0
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" ":1.121" ""

The time between "RefreshAndUpdate" and "Update" is six minutes. The second call to callApperSentinel is one too much IMO. It's triggered by the signal UpdateChanged from PackageKit [1]. this makes Apper 'thinking' that is needs to 'display or update the system'.

Hope this helps,

Martin Kho


[1] qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit [org.freedesktop.PackageKit.UpdatesChanged]

Created attachment 578566 [details]
[PATCH] Don't ask for updates twice

Hi,

As mentiond in my previous comment there was an update request after a RefreshAndUpdate request. This patch is meant to prevent from this behaviour. It's rather easy. "when apper had just asked for a RefreshAndUpdate (meaning apper is still active) don't ask for an update again, even PackageKit is telling to do so". The patch is somewhat bigger, because there was a very little change that a variable was used before it was inititalized.

Hope this helps.


Martin Kho

Hi Rex,

Thanks for bringing my patch to the attention upstream. Though I've a little bit the feeling that I misuse your autority, I hope you don't mind :-)

Martin Kho

Don't worry, I've talked to the Apper upstream developer on IRC (he's a regular on #fedora-kde, even though he personally runs Kubuntu and/or Debian), he appreciates your work on this bug.

Indeed, taking 'http://fedoraproject.org/wiki/Wiki#Above_all_else' (a wee bit out of context, but still applicable in general to many things): 

Above all else

Be bold. Don't worry about memorizing all the rules before starting - just dive in, knowing that there's plenty to learn, and ask for help and feedback along the way. People will cheerfully correct you if you ask; it's better to try doing something quickly and then ask if you got it right (all edits on the wiki are reversible) than to not make an edit because you're afraid of "doing something wrong." We absolutely love to see new people try and learn, and will jump in and lend a hand when asked, or if we spot something.

Hi,

Patch apper-0.7.1-wakeups.patch contains the addition (1) in apperd.cpp that has two contra-effects:

1) It 'wakes up' a call to RefreshAndUpdate, that was 'solved' with addition (2). The origional problem is brought back in again :-(

2) More serious is that it 'blocks' doing a real update. When you press apply in apper, it resolves dependencies, finishes and shows the updates.


(1)
+    
+    if (tids.isEmpty()) {
+        // update the last time the cache was refreshed
+        // TODO PackageKit should emit a property change for this
+        m_lastRefreshCache = getTimeSinceRefreshCache();
+    }

(2)
+
+            // Invalidate the last time the cache was refreshed
+            m_lastRefreshCache = QDateTime();

I've tried to remove (1) and everything seems fine. I could update available packages. No unnecessary RefreshAndUpdates.

Martin Kho

Hi,

One little correction: point 1) isn't caused by patch (1). The 'wake ups' are happening because PackageKit doesn't honour normal (not forced) calls to Refresh and/or Update when there are already updates available (1). "PackageKit raises it's middle finger, and says do something with the available updates first, then we can talk about your next call." And so the refresh-cache would not be reset, causing the 'wake-ups'. They are harmless in sofar I can see, but IMHO not very nice.
A fix could be to prevent the apper daemon from doing anything when apper-sentinel is active.

Martin Kho

(1) Currently some dependencies are not met for libsmbclient. So apper-sentinel is 'permanently' active. A good testcase to see what is happening. :-)

I saw the stuck behavior wrt the current broken samba4 update too.

so, any concrete short-term suggestions?  Drop (-wakups) patch2?  apply yours?  wait?

Created attachment 579163 [details]
[PATCH] revert part of upstream patch + some extra's

Hi Rex,

If've created a patch to revert the blocking part (comment #52) and adds the suggested changes in comment #48 and #53. As soon as upstream comes with better solutions it's easy to drop this patch again.

What do you think, worth doing?


Martin Kho

Hi,

Note: I'm running apper with this patch now. I could install all packages and apper-sentinel is sitting in my systray. No unnecessary wakeup :-)

Martin Kho

PackageKit-0.7.4-1.fc17, apper-0.7.1-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-6580/apper-0.7.1-4.fc17,PackageKit-0.7.4-1.fc17

Hi,

For me apper-0.7.1-4 (and PackageKit-0.7.4-1) works fine. 

There is, however, another bug that blocks cache-refreshes after a succesfull update that needs no reboot/logout. I've opened a report upstream [1].

Shall I open a bugreport in Fedora bugzilla to track this bug?


Martin Kho

[1] https://bugs.kde.org/show_bug.cgi?id=298893

Hi,

Hum ... upstream did a nice job with version PackageKit 0.7.4-1. :-( For me apper seems totally broken, it never ends a transaction.

This is what I get:
[martin@ps-1866 ~]$ qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.PackageKit.GetDaemonState
State:
0       get-updates     /8197_abcadeee_data     state[running] background[0]
1       get-updates     /8198_adbdecec_data     state[ready] background[0]
2       get-distro-upgrades     /8199_eddccaad_data     state[ready] background[0]

After some:
[martin@ps-1866 ~]$ qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.PackageKit.StateHasChanged resume

And:
sudo kill <PackageKit_PID>

apper returns to normal.

This looks not good IMHO :-)

Martin Kho

Hi,

Update:
The issue I mentioned in comment #59 only happens when there are a lot of updates (32). I retried it with one update (after a downgrade) and everything looks okay. As far I could see in the 'mass update' there were no updates related to PackageKit or apper.

Martin Kho

PackageKit-0.7.4-1.fc17, apper-0.7.1-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

oops, sorry about the auto-close, will re-open until we have a fix for f16 in stable updates.

Hi,

Forget all the noise in comments #59 and #60. It looks like it were only temporary hick ups. Besides they has nothing to do with this report :-) Apper  still works fine.


Martin Kho

apper-0.7.1-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.