Bug 832193 - kded4 is "not running" after updating apper from 0.7.1-5 to 0.7.2-1
kded4 is "not running" after updating apper from 0.7.1-5 to 0.7.2-1
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kdelibs (Show other bugs)
16
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 15:49 EDT by Xavier Hourcade
Modified: 2013-02-13 18:35 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 18:35:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Set of logs for "lisa" and "homer" users (see Additional info) (1.15 MB, application/x-gzip)
2012-06-14 15:49 EDT, Xavier Hourcade
no flags Details

  None (edit)
Description Xavier Hourcade 2012-06-14 15:49:08 EDT
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):

  kdelibs-4.8.3-1.fc16.x86_64
  apper-0.7.1-5.fc16.x86_64 - all good
  apper-0.7.2-1.fc16.x86_64 - rather(*) bad

How reproducible:

  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"
  2. Shutdown
  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
     Copied ~/.kde/Autostart/MSNotebookOpticalMouse3000.sh 
     (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).

Actual results:

  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).


Expected results:

  kded4 is launched successfully, and keep running.

Additional info:

   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.
Comment 1 Xavier Hourcade 2012-06-14 15:56:13 EDT
s/SUG34/SIG34/ ^^
Comment 2 Rex Dieter 2012-06-14 16:00:01 EDT
for giggles, mind setting in  /etc/sysconfig/prelink:
PRELINKING=no

and manually re-run:  
/etc/cron.daily/prelink

and the restart system.

See if this is all still reproducible.
Comment 3 Xavier Hourcade 2012-06-14 18:21:38 EDT
(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.
Comment 4 Xavier Hourcade 2012-06-14 18:25:09 EDT
Also, Apper's settings were still set to "Never" check updates, only the Apper service was activated then de-activated.
Comment 5 Xavier Hourcade 2012-06-14 18:48:41 EDT
As a summary for those experiencing this issue, currently :

Workaround (1)
  Once the session start has complete, launch kded4 again manually from KRunner
  [Alt]+[F2] kded4 [Enter]

Workaround (2)
  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 :)

Workaround (3)
  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
Comment 6 Xavier Hourcade 2012-06-16 09:47:49 EDT
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 ?
Comment 7 Fedora End Of Life 2013-01-16 15:01:58 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Fedora End Of Life 2013-02-13 18:35:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.