Red Hat Bugzilla – Bug 832193
kded4 is "not running" after updating apper from 0.7.1-5 to 0.7.2-1
Last modified: 2013-02-13 18:35:24 EST
Created attachment 591918 [details]
Set of logs for "lisa" and "homer" users (see Additional info)
Description of problem:
kded4 is found not to be running, once KDE session has completed
loading, under some conditions.
Version-Release number of selected component (if applicable):
apper-0.7.1-5.fc16.x86_64 - all good
apper-0.7.2-1.fc16.x86_64 - rather(*) bad
Always here (*). This seems random/illogical to some extent,
I would bet this is related to multi-threading.
(*) once I figured the following steps
Steps to Reproduce:
1. Create a new user "lisa"
3. Boot and login into KDE as "lisa"
This was *once* enough to get the Actual results" here.
But, then, it wasn't reproducible. Here is another series of steps which *did* let me reach a 100% reproducible state so far (4 logins).
I am not sure which of the following really triggers this issue, I essentially did reproduce a few settings from my daily work profile until I got a minimal "winning combination", which would always produce the issue while applied to a new, fresh user profile (so the winner was "homer", that's just "bad luck" -- sorry ^^)
1. Create a new user "homer"
2. Reboot and login into KDE as "homer". No issue.
3. Add Lancelot applet to panel
Add Moon applet to Desktop
4. Reboot and login into KDE as "homer". Still no issue.
5. Change desktop theme to Oxygen
(all it does, is : xmodmap -e "pointer = 1 2 3 4 5 6 7 9 8 10 11" )
6. Reboot and login into KDE as "homer".
Now, the issue is consistent for that user (once after each reboot).
No other setting (nor animal) were harmed in this user profile.
Please note, in facts in took a total of 4 "homer" sessions to reach
that "always reproducible state" (I think I did step 5 in two steps,
rebooting in between, but I assume this won't make a difference anyway).
kded4 is simply "not running".
Quite a few things go pear shape when this happens, as can be expected,
One of the most obvious and immediate symptoms are the "icon fall back"
in notification area/tray (they switch to the oldish colour set), or
various UIs no longer being accessible (PrintScreen keyboard binding to
run Ksnapshot, Power Settings UI being "crossed" with an error msg, etc.).
No error dialogue shows up, no crash detected by ABRT, kded4 silently stops.
No error message in logs either (well, which I could identify myself)
I assume this absence of messaging/ABRT handling, is a distinct issue
on its own (ABRT is doing its job otherwise here).
kded4 is launched successfully, and keep running.
Attaching an archive for both "lisa" and "homer" users
(dmesg, /var/log/messages|Xorg|kdm|secure, ps aux and .xsession-errors)
System is fully up to date -- running kmod-nvidia also, if this matters.
From my experience in my own daily work KDE profile, over the past weeks :
* Launching kded4 manually from KRunner, "fixes" it until next reboot
* Logout/login, "fixes" it until next reboot
* Downgrading apper to 0.7.1-5 did permanently solve the issue 5+ times.
Re-upgrading apper to 0.7.2-1 did permanently re-introduce it 5+ times.
* Removing the "Moon" applet from Desktop, instead of downgrading apper,
seems to have fixed permanently the issue today ^^ (2 boots already).
I always had the issue with apper 0.7.2-1. Lancelot, Oxygen and my xmodmap
scripts are still there.
* Attaching gdb to each and every kded4 process (scripted, each gdb
running within a distinct window within a `screen`, as root from tty2,
issuing "continue" and ignoring SUG34 -- otherwise, it would keep pausing).
Running this script seem to have also "fixed" the issue :
I got plenty of traces but no abnormal termination or crashes.
kded4 was still running once the session load had completed, each time.
for giggles, mind setting in /etc/sysconfig/prelink:
and manually re-run:
and the restart system.
See if this is all still reproducible.
(one more erratum : gdb instances were run as user, not root of course)
(In reply to comment #2)
> See if this is all still reproducible.
Yes, this is still perfectly reproducible after un-prelinking entirely and a couple of reboots (both in the "homer" profile, and my xaho profile).
Actually, I was expecting the issue to disappear too ...at least as a side effect : the system being much slower to start cf. disk accesses, I thought kded4 would then behave the same as it was, while I was running my "gdb.them.all.sh" script. Being slown down, it was running fine each time -- but no, it *still* unexpectedly closes.
NB. Before to unprelink and test, I wanted to bring the bug conditions again in my daily work profile : so I first added the moon back and restarted, which caused no issue :D Next I did re-enabled the KDE Apper service and rebooted again, then bug occurred straight away.
Next I attempted to disable the service again, met https://bugs.kde.org/show_bug.cgi?id=283117 then succeeded in disabling it, and the issue is gone again.
Also, Apper's settings were still set to "Never" check updates, only the Apper service was activated then de-activated.
As a summary for those experiencing this issue, currently :
Once the session start has complete, launch kded4 again manually from KRunner
[Alt]+[F2] kded4 [Enter]
Apper > Settings > General Settings >
Change "Check for Update" to "Never"
System Settings > System Administration > Startup and Shutdown >
Service Manager >
Stop then Uncheck "Apper Monitor"
If System Settings crash as in the KDE bug mentioned here before,
just presevere :)
Downgrade apper to 0.7.1-5, and exclude apper from further updates.
$ wget http://kojipkgs.fedoraproject.org/packages/apper/0.7.1/5.fc16/x86_64/apper-0.7.1-5.fc16.x86_64.rpm
# yum downgrade apper-0.7.1-5.fc16.x86_64.rpm
(then while updating)
# yum update -x apper
Few more clues maybe, after further attempts yesterday:
"Homer" account, as resulting from steps in comment #0 - is still systematically presenting the issue (another 6/6 times).
It did also present the exact same types of exceptions, as I had seen before with my daily account, preventing kded4 from quitting :
* trying to "./gdb.them.all.sh kded4" again (3/3)
* some Dolphin window I had left open before quitting previous session,
and was therefore automatically re-open after reboot (1/1)
NB. in my daily account, the once the issue didn't occur, was while I had
left Kopete open -- however the bug *had* shown up the second time.
As per the host config, if it may matter (?)
* WLAN/web access is permanent i.e. accessible very early by KDE services
(system connection, didn't try to disable it yet)
* All partitions are located on LVs within a LUKS'd VG
(which implies much disk access, maybe this delay some of the services ?)
* I don't seem to miss prelinking here ! Maybe LUKS was hiding its gain ?
Could dbus-monitor help ? Not sure how to use it in this case. Hacking the startkde script ? Re-building kdeinit wrapper or kded4 with more verbose flags if any ?
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 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 WONTFIX if it remains open with a Fedora
'version' of '16'.
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 prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 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 to click on
"Clone This Bug" and open it against that version of Fedora.
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.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.
Thank you for reporting this bug and we are sorry it could not be fixed.