Bug 983110 (heisenbug)

Is polkit-kde-authentication-agent-1 running in your session?

It should be, see 
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop

File exists and polkid is running.

$ cat /usr/share/autostart/polkit-kde-authentication-agent-1.desktop 

[Desktop Entry]
Name=PolicyKit Authentication Agent
Name[da]=PolicyKit autentificeringsagent
Name[en_GB]=PolicyKit Authentication Agent
Name[et]=PolicyKiti autentimisagent
Name[pt]=Agente de Autenticação do PolicyKit
Name[sv]=Policykit behörighetskontrollverktyg
Name[uk]=Агент розпізнавання PolicyKit
Name[x-test]=xxPolicyKit Authentication Agentxx
Comment=PolicyKit Authentication Agent
Comment[da]=PolicyKit autentificeringsagent
Comment[en_GB]=PolicyKit Authentication Agent
Comment[et]=PolicyKiti autentimisagent
Comment[pt]=Agente de Autenticação do PolicyKit
Comment[sv]=Policykit behörighetskontrollverktyg
Comment[uk]=Агент розпізнавання PolicyKit
Comment[x-test]=xxPolicyKit Authentication Agentxx
Exec=/usr/libexec/kde4/polkit-kde-authentication-agent-1
Terminal=false
Type=Application
Categories=
X-Desktop-File-Install-Version=0.15
OnlyShowIn=KDE;


$ ps aux|grep polkit
polkitd    693  0.0  0.1 514128  6788 ?        Ssl  Jul08   0:01 /usr/lib/polkit-1/polkitd --no-debug
mholec   15451  0.0  0.0 112648   928 pts/2    S+   13:58   0:00 grep --color=auto polkit

Yes, you don't have the agent running. Did you notice its crash by any chance? ABRT or DrKonqi usually catch it. I cannot think of any other reason why it shouldn't start.

Not polkitd, I asked about polkit-kde-authentication-agent-1 process

Yes, it's obvious polkit-kde-authentication-agent-1.desktop is present in /usr/share/autostart/, but process polkit-kde-authentication-agent-1 is not running, only polkid.

As suggested by Rex, I tracked down the problem is in default SELinux policy, even there is not SELinux alert. When I run "setenforce 0" and relogin, polkit-kde-authentication-agent-1 is running.

And following appears in: /var/log/audit/audit.log

type=USER_ACCT msg=audit(1373545961.962:486): pid=3190 uid=1000 auid=1000 ses=2 subj=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="mholec" exe="/usr/lib/polkit-1/polkit-agent-helper-1" hostname=? addr=? terminal=? res=success'


This issues is not only causing problems with polkit, but also with session shutdown/logout (countdown dialog doesn't appear), KMix and applications in Autostart (like ~/.config/autostart/pidgin.desktop) doesn't start either.

"restorecon -Rv /" won't help, only working workaround is "setenforce 0".

OK, reassigning to selinux-policy for advice/guidance at this point.

Note: I can't reproduce it with KDM, but when I switch back to GDM and can still reproduce it.

Could you re-test it in permissive mode and then run

# ausearch -m avc,user_avc -ts recent

----
time->Thu Jul 11 16:24:51 2013
type=USER_AVC msg=audit(1373552691.260:483): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received setenforce notice (enforcing=0)  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Ok, could also re-test it with

# semodule -DB

re-test

# ausearch -m avc,user_avc -ts recent


Also what does

# ps -eZ |grep initrc

Created attachment 915731 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

I will need to try to reproduce it. So KDE+virt-manager, right?

KDE + GDM. Look if polkit-kde-authentication-agent-1 process is running.

Martin,
is this working for you in permissive mode?

It works for me. I am able to start Virtual Machine Manager without problems.

(In reply to Miroslav Grepl from comment #17)
> It works for me. I am able to start Virtual Machine Manager without problems.

I can re-create the same issue in the description of this bug using KDE and Virt-Manager.

However, I am unable to start Virtual Manager with SELinux disabled. My workaround is to open  a terminal window, su - root, and run virsh

Not positive what information you need to debug:

[root@localhost ~]# sestatus                                                            
SELinux status:                 disabled                                                

[root@localhost ~]# rpm -qa | grep polk                                                 
polkit-0.111-2.fc19.x86_64
polkit-qt-0.103.0-7.fc19.x86_64
polkit-kde-0.99.1-1.20130311git.fc19.x86_64
polkit-pkla-compat-0.1-2.fc19.x86_64

[root@localhost ~]# rpm -qa | grep virt
libvirt-client-1.0.5.2-1.fc19.x86_64
libvirt-daemon-config-nwfilter-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-storage-1.0.5.2-1.fc19.x86_64
libvirt-daemon-kvm-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-qemu-1.0.5.2-1.fc19.x86_64
libvirt-daemon-config-network-1.0.5.2-1.fc19.x86_64
virt-viewer-0.5.6-1.fc19.x86_64
virt-manager-common-0.10.0-1.fc19.noarch
libvirt-daemon-driver-lxc-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-libxl-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-interface-1.0.5.2-1.fc19.x86_64
virt-manager-0.10.0-1.fc19.noarch
virt-install-0.10.0-1.fc19.noarch
redland-virtuoso-1.0.16-2.fc19.x86_64
libvirt-glib-0.1.6-1.fc19.x86_64
libvirt-daemon-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-nwfilter-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-uml-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-nodedev-1.0.5.2-1.fc19.x86_64
virtuoso-opensource-6.1.6-3.fc19.x86_64
libvirt-daemon-driver-network-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-secret-1.0.5.2-1.fc19.x86_64
libgovirt-0.1.0-1.fc19.x86_64
libvirt-python-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-xen-1.0.5.2-1.fc19.x86_64
libvirt-1.0.5.2-1.fc19.x86_64

[root@localhost ~]# uname -r
3.9.9-301.fc19.x86_64

virt-manager works for me in permissive mode. Remember, you have to relogin when you switch between enforcing and permissive modes, because polkit client starts with session. I haven't tested this with SELinux disabled.

I use enforcing mode by default.

Michael,
could you try to execute

# chcon -t policykit_auth_exec_t /usr/libexec/kde4/polkit-kde-authentication-agent-1

and re-test it?

Martin,

I switched to permissive and rebooted as I am unable to relogin and I had the same result.

Miroslav,

I followed your instructions and same result.

[root@localhost ~]# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
[root@localhost ~]# chcon -t policykit_auth_exec_t /usr/libexec/kde4/polkit-kde-authentication-agent-1
[root@localhost ~]# echo $?
0

Does /usr/libexec/kde4/polkit-kde-authentication-agent-1 start now when you login?

I have a feeling this is dbus dropping packets and not logging it.

(In reply to Daniel Walsh from comment #23)
> Does /usr/libexec/kde4/polkit-kde-authentication-agent-1 start now when you
> login?
> 
> I have a feeling this is dbus dropping packets and not logging it.

/usr/libexec/kde4/polkit-kde-authentication-agent-1 is not running when I check the running proceses.

If I start /usr/libexec/kde4/polkit-kde-authentication-agent-1 from a terminal window, Virtual Machine Manager starts immediately. Great. Thank you!

How do I set /usr/libexec/kde4/polkit-kde-authentication-agent-1 to start auto-magically?

I reported related issue: #986613

(In reply to Martin Holec from comment #5)

> "restorecon -Rv /" won't help, only working workaround is "setenforce 0".

I'm certainly no SELinux expert, this distro is first I've ever used it, but...
I tried:
Logged out,
Login root
setenforce 0
logout and back in as normal user, no change.

Even logging in desktop as root fails most times.

So question... Does this prove or disprove that SeLinux is not a factor?

If it does not work in permissive mode then it is not a SELinux issue.

To everybody able to reproduce the bug: With which display manager does this happen, please?

I can reproduce it only with GDM.

I can reproduce this in KDM — KDE Display Manager

I can reproduce this in KDM — KDE Display Manager

In permissive mode?

KDE for me.

For my symptoms, but #986613, yes I it happens in permissive mode as well as enforcing mode.

If you don't have kmix working as well as the polkit agent, the bug's not in polkit-kde package...
Tentatively reassigning to kde-workspace - I have a slight suspicion there could be a bug somewhere around PAM or the env settings but it seems it isn't in the DE as you can reproduce it in different ones... But there's still the possibility it's in dbus.

*** Bug 991845 has been marked as a duplicate of this bug. ***

reporting : GDM seems to fix the problem , been using it for 2 days and no sign of trouble

reporting back : gdm does not fix the problem , problem is back again , and i am sick of this bug !

I reproduced this right now with F19 installed from the local PXE and a local repo mirror.
Software selection was only the KDE desktop, no optional packages.
Happened right after boot, no settings changed, that means logged in through KDM.

So it seems there's a problem in kdeinit4/klauncher communication:
klauncher reports "nothing to read, kdeinit4 must be dead" when i tried to start konsole from the menu.
Also, I can't reproduce the bug with enforcing=0 in kernel command line but the ausearch command you provided doesn't print anything else than <no matches>
Any clue what to do next, please, Daniel and Miroslav?
Thank you.

*** Bug 986613 has been marked as a duplicate of this bug. ***

i have a question : after reading all your comments i found out that when problem occurs process /usr/libexec/kde4/polkit-kde-authentication-agent-1 is not started , it's not there is `ps` 

what are the possible reasons that makes this process not start ?

Re: comment 41

note subject of bug, and that polkit-kde = polkit-kde-authentication-agent-1 

The only clue(s) we have so far is comment #39

The problem I'm seeing is well described under bug 986613.
As that bug has been closed as a duplicate of this one, I'll continue here.

System setup:
--------
3.10.3-300.fc19.x86_64
default.target -> /lib/systemd/system/multi-user.target
selinux disabled
logged into tty as root
default desktop KDE
startx

--------
95% of the time:
Desktop startup sound does not play.
Clicking Konsole icon times out with error.
Logoff button does nothing.
After Konsole launch times out, Konsole launch works normally, but
still no sound and logoff button still ignored.
No errors in /var/log/messages .

--------
5% of the time:
Desktop startup sound plays.
Konsole launch works immediately.
Logoff button works normally.
Sound works normally.

--------
Conclusion:
This is very likely not a permission problem (root, no selinux), but it
is likely a race condition (occasionally works as expected).

Clay, for you, once logged in does, systemd-loginctl list your session?

Me, for example,
$ systemd-loginctl
   SESSION        UID USER             SEAT            
         1       1000 rdieter         seat0

And when you said "(root, no selinux)", are you logging in as root?

(note: selinux enabled now - does not change bug behavior)

Signed on pts/0 as root .

# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

# systemd-loginctl
   SESSION        UID USER             SEAT
       256          0 root             seat0

Output is the same before and after startx .

*** Bug 994647 has been marked as a duplicate of this bug. ***

I think I can confirm that 5% of the time everything works... today I think for the first time I heard sound when loggin in, kmix and klipper are there and logoff button works! here is my systemd-loginctl on this working session.

$ systemd-loginctl
   SESSION        UID USER             SEAT            
         1       1000 one              seat0           

1 sessions listed.

Hello,

I found something strange with the kde settings package.
I search for kde settings in installed packages:

yum list installed | grep kde-settings
kde-settings.noarch              19-23.1.fc19                          @updates 
kde-settings-kdm.noarch          19-23.fc19                            @anaconda
kde-settings-kdm.noarch          19-23.1.fc19                          @updates 
kde-settings-ksplash.noarch      19-23.1.fc19                          @updates 
kde-settings-plasma.noarch       19-23.1.fc19                          @updates 
kde-settings-pulseaudio.noarch   19-23.1.fc19                          @updates

And, as you can see, the are 2 kde-settings-kdm.noarch package installed.
Can our problem come from this ?

YC

The problem with kde-settings-kdm is bug #989145 . Should be unrelated to this bug.

ycollet, this is unrelated to this bug, unfortunately. Please run:
rpm -e --noscripts kde-settings-19.23.fc19
to get rid of the additional one.

Thanks for the information. I already did that and you were right, this is not related to this bug.

YC

I have 3 computers with a fresh installation of Fedora 19 KDE (one with an Intel video card, one with a NVidia, and one with a AMD/ATI), and the only computer on which I experience the problem described here is the one with the NVidia card, when using the proprietary driver (everything seems to work fine when using the nouveau driver).

I don't know if this is related, but that is what I observed so far.

I also have a nvidia card but not with the closed source driver.

Intel graphics card here just for the record...

I found a .xsession-errors in my home directory.
I attached it to the bug report. Maybe it will help.

Created attachment 788563 [details]
the session error file

Looks like this bug could be a GLib bug (which can also hit Qt through event loop integration): I see several "(process:1xxx): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed" errors in that .xsession_errors log. Those are all processes terminating with a fatal error due to an assertion failure in GLib.

Should we reassign this bug to glib2?

There are no .xsession_errors in my testing.

I still wonder if my comment on bug #986613, when I mentioned that when bug #974705 crashed, this was the only time in recent memory that the desktop and all related tasks started CORRECTLY.  Yes, when the process 

connection.py:651:call_blocking:DBusException: org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.services.manage:

crashed, the desktop started correctly.

I wanted to activate the debug flag of systemd to have more informations relatd to this bug.
But before that, I've done:

restorecon -Rv .local .kde


Then I restarted my PC and, in grub, I added the following option to the linux commande line:

systemd.log-level=debug

Everything went fine: kmix started nicely, and I was able to logout using the plasma applet.
But now, since my last try, everything works fine. I don't added the systemd flag in grub anymore, but the bugs has not shown up again...
Maybe the restorecon command has done something good.

Kevin, this doesn't really seem related. I have these errors in my .xsession-errors too, even though not so often... Everything is running fine though.

ycollet, yeah, I experienced something similar but by different approach. Once I disabled SELinux enforcing mode for one boot (by adding enforcing=0 to the kernel command line), it stopped happening even for the consecutive boots with enforcing SELinux.

After updating selinux-policy from updates-testing it seems to work most of the time. Can't say that it works every time though.

I have a trick while bug is not fixed (for people annoyed with bug)

before login on kdm, restart the X server

tested with nvidia proprietary and nouveau.. all work, sound, kmix, logout buttons...

Been trying out several things but none worked so i reverted everything (restored from backups). I was looking online for more things to try and 15 minutes later kmix and klipper popped up. polkit-kde has also started and kde debug output for ksmserver has gotten to kcmPhase2Done whereas before it was stuck at kcmPhase1Done. I can only guess that something in the auto start list is freezing everything after it. Everything that has failed to start in this bug report is in some way started through the autostart mechanism except for the logout/shutdown part which in my limited understanding of things runs through ksmserver for session management.

$ ps -e | grep polkit
  480 ?        00:00:00 polkitd
 1390 ?        00:00:00 polkit-kde-auth

$ fgrep ksmserver .xsession-errors
ksmserver(1239) SetAuthentication_local: KSMServer: SetAProc_loc: conn  0 , prot= local , file= @/tmp/.ICE-unix/1239
ksmserver(1239) SetAuthentication_local: KSMServer: SetAProc_loc: conn  1 , prot= unix , file= /tmp/.ICE-unix/1239
ksmserver(1239) KSMServer::autoStart0Done: Autostart 0 done
ksmserver(1239) KSMServer::kcmPhase1Done: Kcminit phase 1 done
ksmserver(1239) KSMServer::autoStart1Done: Autostart 1 done
ksmserver(1239) KSMServer::autoStart2Done: Autostart 2 done
ksmserver(1239) KSMServer::kcmPhase2Done: Kcminit phase 2 done

ksmserver seems to do most of it's autostart stuff through klauncher so i have enabled debug output for that for when i next restart in the hope of discovering more.

*** Bug 877215 has been marked as a duplicate of this bug. ***

*** Bug 1009891 has been marked as a duplicate of this bug. ***

I've also had this problem for some time, and I find that removing konqy_preload.desktop from autostart seems to eliminate the issue fairly reliably. Note... my system is a toshiba satellite p875-s7102 with intel (ivy bridge) graphics.

I didn't get anywhere with my debugging. I did however find what appears to be a bug which could possibly be a cause.

I don't know a lot about how the KDE internals work so i may be wildly off the mark here but this is what i found.

ksmserver calls klauncher [1] (through dbus) in phases (0 - 2). Phase 0 is the window manager etc. Phase 1 is before session restore and phase 2 is after session restore.

The autostart files are loaded in [2] (a part of klauncher) and are run as appropriate according to the phases stated in the .desktop files.

According to all the docs the default phase if none is specified is phase 1 (before session restore). In KAutostart::startPhase() [3] however the default is read as phase 2 (after session restore). That means that all desktop files without an explicit phase (X-KDE-autostart-phase=1) will be started later than expected.

Adding X-KDE-autostart-phase=1 to [4] seems to work for me. I may of course be very wrong and it is just a timing coincidence. I have however rebooted 20 times since adding the line and not a single failure.

If somebody who knows the code a little better doesn't spot a huge flaw in what i found i can report it upstream tomorrow.

[1] - kde-workspace/ksmserver/startup.cpp
[2] - kdelibs/kinit/autostart.cpp
[3] - kdelibs/kdecore/util/kautostart.cpp
[4] - /usr/share/autostart/polkit-kde-authentication-agent-1.desktop

Does not work for me. I installed fresh GNOME awhile ago then removed it and installed KDE.

(In reply to john5342 from comment #68)
> If somebody who knows the code a little better doesn't spot a huge flaw in
> what i found i can report it upstream tomorrow.

I reported the autostart phase default issue upstream anyway [1]. It is if nothing else a documentation bug. If that wasn't the cause then i am out of ideas but it is at least working for me.

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

I can reproduce this in KDM — KDE Display Manager.
I'm running Fedora 19 with all updates installed until today.
I have 2 machines where the problem exists:
- Desktop Intel i5 processor, nouveau, installed Fedora from net-install USB (default Gnome), and installed KDE by 'yum install @kde-desktop'.
- Laptop Intel i5 processor, integrated intel HD4000 graphics (no nouveau), installed Fedora from live-KDE USB (default KDE)
Another machine does not show the problem:
- Laptop AMD processor, installed Fedora from live-KDE USB (default KDE)

Sometimes, the issue doesn't occur.
If it occurs, the following things go wrong:
- KMix isn't running.
- Installing an application via 'apper' fails when it should ask you for a password.
- Logout/Shutdown button doesn't work.

Way to fix things (if it happens): Run 'killall ksmserver' and login again.
Mostly, the second time, things are fixed.

I can reproduce this in KDM — KDE Display Manager.
I'm running Fedora 19 with all updates installed until today.
I have 2 machines where the problem exists:
- Desktop Intel i5 processor, nouveau, installed Fedora from net-install USB (default Gnome), and installed KDE by 'yum install @kde-desktop'.
- Laptop Intel i3 processor, integrated intel HD4000 graphics (no nouveau), installed Fedora from live-KDE USB (default KDE)
Another machine does not show the problem:
- Laptop AMD processor, installed Fedora from live-KDE USB (default KDE)

Sometimes, the issue doesn't occur.
If it occurs, the following things go wrong:
- KMix isn't running.
- Installing an application via 'apper' fails when it should ask you for a password.
- Logout/Shutdown button doesn't work.

Way to fix things (if it happens): Run 'killall ksmserver' and login again.
Mostly, the second time, things are fixed.

I have 3 machines, all running F19. Two of them were updated within the last 2 days to kernel 3.11.1-200, as well as a LOT of new KDE stuff. All 3 used to work perfectly. Now the 2 that were updated exhibit most of these troubles. The 3rd machine has not been updated, and still works fine (it is a laptop, video driver seems to be "video" or i915, not really sure about this one).

The worst offender is using the nvidia driver (which can cause some sound problems due to the HDMI sound support). Initially this would mostly fail as already reported, and no polkit-kde-authentication-agent-1  is running. No login sounds, Konsole does work, but not any Leave menu entries, and no kmix or klipper. I tried the suggested fix for adding the Autostart-phase to the desktop file, and now I have everything running, but still no login sound.

The second machine also has a nvidia card, but is using the nouveau driver. Since it was updated it has stopped playing any login sounds, but other things seem to be OK.

All machines have SELINUX=DISABLED.
I only have KDE installed, no GNOME, so I believe I am using KDM.

(In reply to Al from comment #73)
> but still no login sound.

That is by design starting with KDE 4.11 i believe.

(In reply to Elias Vanderstuyft from comment #71)
> I can reproduce this in KDM — KDE Display Manager.
> I'm running Fedora 19 with all updates installed until today.
> I have 2 machines where the problem exists:
> - Desktop Intel i5 processor, nouveau, installed Fedora from net-install USB
> (default Gnome), and installed KDE by 'yum install @kde-desktop'.
> - Laptop Intel i5 processor, integrated intel HD4000 graphics (no nouveau),
> installed Fedora from live-KDE USB (default KDE)
> Another machine does not show the problem:
> - Laptop AMD processor, installed Fedora from live-KDE USB (default KDE)
> 
> Sometimes, the issue doesn't occur.
> If it occurs, the following things go wrong:
> - KMix isn't running.
> - Installing an application via 'apper' fails when it should ask you for a
> password.
> - Logout/Shutdown button doesn't work.
> 
> Way to fix things (if it happens): Run 'killall ksmserver' and login again.
> Mostly, the second time, things are fixed.

kiall ksmserver worked for me.

After adding the autostart-phase to polkit-kde-authentication-agent-1.desktop it booted correctly once. I then tried to log out and back in, and the klipper tool was delayed in starting, and the Leave menu was unresponsive until the tool showed up, then all was fine. A reboot does the same thing, only kmix and klipper are both delayed about 10 or 15 seconds in starting. Based on John's comment I am no longer expecting any login or logout sound.

It might not be related, but since the last update my boot time has increased a good bit, and it spits out some error messages that go by way to fast for me to even read. While it used to just get started with those different shaded blue lines and then jump directly to the KDM login screen, now they take a good bit of time, and the "Fedora 19" shows up on the right side, then some messages go by, and finally gets to the login screen. Used to get to that screen in a couple of seconds, now it is more like 10 seconds.

(In reply to john5342 from comment #68)
> I didn't get anywhere with my debugging. I did however find what appears to
> be a bug which could possibly be a cause.
> 
> I don't know a lot about how the KDE internals work so i may be wildly off
> the mark here but this is what i found.
> 
> ksmserver calls klauncher [1] (through dbus) in phases (0 - 2). Phase 0 is
> the window manager etc. Phase 1 is before session restore and phase 2 is
> after session restore.
> 
> The autostart files are loaded in [2] (a part of klauncher) and are run as
> appropriate according to the phases stated in the .desktop files.
> 
> According to all the docs the default phase if none is specified is phase 1
> (before session restore). In KAutostart::startPhase() [3] however the
> default is read as phase 2 (after session restore). That means that all
> desktop files without an explicit phase (X-KDE-autostart-phase=1) will be
> started later than expected.
> 
> Adding X-KDE-autostart-phase=1 to [4] seems to work for me. I may of course
> be very wrong and it is just a timing coincidence. I have however rebooted
> 20 times since adding the line and not a single failure.
> 
> If somebody who knows the code a little better doesn't spot a huge flaw in
> what i found i can report it upstream tomorrow.
> 
> [1] - kde-workspace/ksmserver/startup.cpp
> [2] - kdelibs/kinit/autostart.cpp
> [3] - kdelibs/kdecore/util/kautostart.cpp
> [4] - /usr/share/autostart/polkit-kde-authentication-agent-1.desktop

Does not work for me. At least not on this system:
(In reply to Elias Vanderstuyft from comment #72)
> - Desktop Intel i5 processor, nouveau, installed Fedora from net-install USB (default Gnome), and installed KDE by 'yum install @kde-desktop'.

Did some testing today on a box that I can reproduce this fairly reliably...

Even with Session management disabled (ie, "Start with an empty session" option picked), it still happens for me on initial login from boot.  That probably rules out the ksmserver being to blame.

Tested both kdm and lightdm too, for giggles, in case it was DM-specific.  no difference.

To clarify, ksmsever does still handle autostart'd apps, I only meant that I likely ruled out session save/restore as one possible trouble spot.

(In reply to Rex Dieter from comment #79)
> To clarify, ksmsever does still handle autostart'd apps, I only meant that I
> likely ruled out session save/restore as one possible trouble spot.

Correct. The stall happens before KSMServer::autoStart1Done() is called but the session restore is started inside KSMServer::autoStart1Done() before queueing autostart phase 2. 

I have also tried checking the dbus part of things but running dbus-monitor seems to slow things down enough that i can't trigger the failure.

The next thing i am going to try is some rebuilds of kdelibs and kde-workspace with some more debug output to help narrow it down but i am halfway around the world at the moment so it's going to have to wait until the weekend at least unless somebody beats me to it.

I'm having this issue in a fresh install of KDE Fedora 19, on a Dell 6520 Latittude with Intel graphics. I'd been experiencing this problem intermittently after installing KDE Fedora 19 a few months ago, but most of the time things worked as expected. I did a clean install after switching to Kubuntu for a few weeks. Now the problem is much worse than before. 

Previously, the only issues I had were the logout, restart, etc buttons and my "open konsole" shortcut not working. And that only now and then. Now it's almost everytime I log in, in addition to kmix and krunner not starting. Overall, the desktop seems much less stable than before. I'm not sure what changed, as I kept the system up to date before. But, from what I've been reading, it sounds like this occurs most often on a fresh install. 

I've resorted to logging into Gnome now, so I can get some work done. No problems so far in Gnome, other than the mouse pointer disappearing after resume from suspend.

(In reply to john5342 from comment #80)
> The next thing i am going to try is some rebuilds of kdelibs and
> kde-workspace with some more debug output to help narrow it down but i am
> halfway around the world at the moment so it's going to have to wait until
> the weekend at least unless somebody beats me to it.

Thank you for your time and effort.
If you need me to test something, I'll do it (I'll try to make some time), because this bug NEEDS to be fixed as soon as possible!

This problem only occurs for me logging in via KDM. I tried logging in via GDM several times in a row, and everything worked fine. My system is up-to-date with YUM. I have intel, not nvidia, graphics.

On a lark, due to some other related bugs, like bug #983688 , bug #987242 , I resorted to clearing my systemd journal,
rm -rf /var/log/journal/*
and rebooted.

My @work machine where I could very reliably reproduce *this* bug with any DM (including kdm, lightdm, gdm, sddm), now functions happily, at least for the last 6 reboots.  I'll continue testing and booting several more times, but I think we may be on to something here.

I ran into a similar response on my machine here. The boot process had gotten very lengthy and after searching and looking at other posts elsewhere it looked like either clearing /var/log/journal or renaming it (to disable the logging) might help. It has helped the booting immensely, and I noticed that for the first few boots this bug also seemed better. Sadly, after some more use it has returned.

I wonder if we're all having the same bug. Seems like there's a lot of variation in the symptoms, with the only common one being the logout button not working. 

KDE was pretty much unusable for me after the fresh install, no matter how many times I rebooted or logged back in. Desktop applications not running, entries missing from settings menus... All kinds of wierd stuff. 

Then I tried logging into kde from GDM, and everything's worked great since. When I get some time, I'll try KDM again, and see what shows up in the logs. Does KDM have its own log, or is it all in /var/log/messages?

I'm relatively new to Fedora. I use RHEL 6 at work, but it's all Gnome.

On a computer that I have in which I tried Fedora 19 KDE installed by russianfedora images, both live and netinstall, I could reproduce the error on too many occasions, with KDM session managers and SDDM. Many times began functioning properly but booting slowly, and as it was installing software, the error started to occur. On this computer I have finished putting Cinnamon: P

In another computer in which I have installed Fedora 19 KDE on a SSD, also through a netinstall image of russianfedora with and the same as the previous installed, everything works fine now, but the error was reproduced on a couple of occasions almost followed, and since then he has not given.

In Fedora 20, seems to have solved the error affecting the boot time and that from what I've read are related to the error of KDE. Do you know if it works well KDE in Fedora 20?

___________

This is the original message in Spanish, translated into english by google translator. Sorry, but I'm not english speaker:


En un ordenador que tengo en el que he probado Fedora 19 KDE instalado mediante las imágenes de russianfedora, tanto live como netinstall, he podido reproducir el error en demasiadas ocasiones, con los gestores de sesión KDM y SDDM. Muchas veces empezaba funcionando correctamente, aunque iniciando despacio, y a medida que iba instalando programas, el error empezaba a darse. En este ordenador he acabado poniendo Cinnamon :P

En otro ordenador En el que tengo Fedora 19 KDE instalado en un SSD, también mediante una imágen de russianfedora con netinstall y con lo mismo instalado que en el anterior, todo funciona correctamente ahora mismo, aunque se reprodujo el error en un par de ocasiones casi seguidas, y desde entonces no ha vuelto a darse.

En Fedora 20, parece que se han solucionado los errores que afectan al tiempo de inicio y que por lo que he leído están relacionados con este error de KDE. ¿Sabéis si funciona bien KDE en Fedora 20?

carlos (or anyone else still experiencing this bug), can you verify if the workaround of clearing the journal
https://bugzilla.redhat.com/show_bug.cgi?id=983110#c84
does *not* help?

(In reply to Rex Dieter from comment #88)
> carlos (or anyone else still experiencing this bug), can you verify if the
> workaround of clearing the journal
> https://bugzilla.redhat.com/show_bug.cgi?id=983110#c84
> does *not* help?

Well, unfortunately I have had an occasion where it did *not* help:
I powered on the laptop, logged in (via KDM), and experienced this bug.
So I opened a terminal, and executed the following commands as root: "mkdir /root/varLogJournal && mv /var/log/journal/* /root/varLogJournal/" and "poweroff".
After that I powered on the laptop, logged in via KDM, and experienced this bug (again).

This happened on the following machine:
(In reply to Elias Vanderstuyft from comment #72)
> - Laptop Intel i3 processor, integrated intel HD4000 graphics (no nouveau), installed Fedora from live-KDE USB (default KDE)

I also have renamed my journal file, and boot times went from more than 20 seconds to less than 5. However this bug still appears intermittently. When it does the system will take an additional 10 seconds or so after login before it is fully operational.

Well, I tried clearing the journal, switching the DM to KDM, and rebooting. There was no noticeable speed up in boot time. 

Then I logged in and out again several times, and things were working well.

Then I rebooted again, and logged in, and the problem was back.

I tried switching back to GDM, but GDM refuses to recognize my existing user, and wants me to create a new account. There's no apparent way to bypass this. 

I tried switching to lightdm, and logged in. The problem is still there.

So, I guess I'll log into Gnome for now via lightdm. 

KDE works great on my Archlinux laptop, When I resume from suspend, it goes straight to the lockscreen, rather than flashing the desktop like it does in Fedora and Kubuntu. So this seems to be a Fedora specific issue. I may have experienced the broken logout button a couple times in Kubuntu, but I don't remember for sure. 

I found this:

https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1000690

I managed to reproduce this bug logging into KDE via GDM as well.

grep phase /usr/share/autostart/*

/usr/share/autostart/kaddressbookmigrator.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
/usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/kgpg.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/kmix_autostart.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1


Editing the autostart files to reflect the above works for me consistently, however I think it is just masking an underlying issue.

I solved the problem by unchecking KmixD in System Settings --> Service management. Had 100% normal startups since that, which is about 20-25 times.

KmixD seems to restart (or probe somehow) my sound card on launch, I can figure that because it produces a clicking sound (Asus Xonar). I would expect that during kernel boot but not when Plasma launches.

(In reply to Dmitry Slivin from comment #94)
> I solved the problem by unchecking KmixD in System Settings --> Service
> management.

Hmm, I tried that, but even after the first reboot, I still see this issue :(

(In reply to Elias Vanderstuyft from comment #72)
> - Desktop Intel i5 processor, nouveau, installed Fedora from net-install USB (default Gnome), and installed KDE by 'yum install @kde-desktop'.

Scottvalen solution works perfectly for me after more than 20 reboots. The problems I had at the start of KDE have disappeared. I would consider including it as an update patch.

For more information, the error also occurs in the KDE kde-redhat repository in Fedora 20 upgraded from Fedora 19, and on a fresh install of Fedora 20.

Does this error occurs on many computers or it's weird? I have not seen in nearly complaints about websites and forums.

______________


This is the original message in Spanish, translated into english by google translator. Sorry, but I'm not english speaker:



La solución de scottvalen funciona perfectamente para mí después de más de 20 reinicios. Los problemas que tenía al inicio de KDE han desaparecido. Yo consideraría incluirlo como parche en una actualización.

Para más información, el error también ocurre en el KDE del repositorio kde-redhat, en Fedora 20 actualizado desde Fedora 19, y en una instalación fresca de Fedora 20.

¿Este error ocurre en muchos ordenadores o es raro? No he visto casi quejas al respecto en webs y foros.

(In reply to scottvalen from comment #93)
> grep phase /usr/share/autostart/*
> 
> /usr/share/autostart/kaddressbookmigrator.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
> /usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/kgpg.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/kmix_autostart.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-
> autostart-phase=2
> /usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1
> 
> 
> Editing the autostart files to reflect the above works for me consistently,
> however I think it is just masking an underlying issue.

Seems to be working until now.
However now KMix always open in a window at startup, I can't seem to let it only start minimized to tray.

Here's my config, (I removed "/usr/share/autostart/plasma.desktop"):

$ grep phase /usr/share/autostart/*
/usr/share/autostart/kaddressbookmigrator.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/kgpg.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/klipper.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/kmix_autostart.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1

I also removed "/etc/xdg/autostart/pulseaudio.desktop" and "/etc/xdg/autostart/pulseaudio-kde.desktop", but I don't know if it's necessary.

change the line "exec=kmix" for "exec=kmix --keepvisibility" in /usr/share/autostart/kmix_autostart.desktop solves the problem with kmix window. :)

(In reply to carlos.rca185 from comment #98)
> change the line "exec=kmix" for "exec=kmix --keepvisibility" in
> /usr/share/autostart/kmix_autostart.desktop solves the problem with kmix
> window. :)

Thank you, just found out by myself, but nice to report ;)

I am experiencing this error on 7 different computers with different NVIDIA 
cards one with nouveau and others with proprietary drivers (some akmod-built and some installed through NVIDIA installer). This error started to appear at the very beginning of Fedora 19 and survived all updates until now; on some machines I had short periods with normal start-up, but later error was always re-appearing.

All machines are different hardware (one 6-years old laptop, others are AMDs and Intels, with RAM from 8 to 64 Gb), all running 64-bit Fedora 19 with KDE. The video cards are GeForce 7400, 8200, 8600GT/GTX, GTX610, 630, 650. 

This totally does not look like an error that happens in rare weird conditions/setups. At least for me, it manifests itself rather regularly. Presently on one out of 7 machines couple recent reboots were clean of this error; on the other 6 the error appears.

(the symptoms are exactly as described: kmix/klipper does not start, some key bindings like the one for ksnapshot do not work, startup sound does not play; first application started by clicking on plasma panel does not start with the klauncher error popped up after few seconds, but starts fine second time; logout/shutdown/restart button appear to be dead)




(In reply to carlos.rca185 from comment #96)
> Scottvalen solution works perfectly for me after more than 20 reboots. The
> problems I had at the start of KDE have disappeared. I would consider
> including it as an update patch.
> 
> For more information, the error also occurs in the KDE kde-redhat repository
> in Fedora 20 upgraded from Fedora 19, and on a fresh install of Fedora 20.
> 
> Does this error occurs on many computers or it's weird? I have not seen in
> nearly complaints about websites and forums.
> 
> ______________
> 
> 
> This is the original message in Spanish, translated into english by google
> translator. Sorry, but I'm not english speaker:
> 
> 
> 
> La solución de scottvalen funciona perfectamente para mí después de más de
> 20 reinicios. Los problemas que tenía al inicio de KDE han desaparecido. Yo
> consideraría incluirlo como parche en una actualización.
> 
> Para más información, el error también ocurre en el KDE del repositorio
> kde-redhat, en Fedora 20 actualizado desde Fedora 19, y en una instalación
> fresca de Fedora 20.
> 
> ¿Este error ocurre en muchos ordenadores o es raro? No he visto casi quejas
> al respecto en webs y foros.

Have you tried the solution in # 93?

(In reply to carlos.rca185 from comment #101)
> Have you tried the solution in # 93?

I did not (I just start missing stuff manually and use console to restart/shutdown). The solution #93 may work but, apparently, it just masks the underlying bug by altering the startup order so that some lock / race condition times out before preventing processes to start. My message is that the problem appears rather regularly and ubiquitously. Thank you for suggestion; I will try shortly.

I think that despite masking the error. The solution of #93 should be applied at least temporarily until you find the real cause. This error is too annoying to leave it for a long time

______________


This is the original message in Spanish, translated into english by google translator. Sorry, but I'm not english speaker:

Pienso que a pesar de que se trate de enmascarar el error. La solución de #93 debería ser aplicada al menos de manera temporal hasta que se encuentre la verdadera causa. Este error es demasiado fastidioso como para dejarlo así durante mucho tiempo

Currently my best recommended workaround is to disable persistent journal logging, set in /etc/systemd/journald.conf:

Storage=volatile

or temporarily clear journal contents by
rm -rf /var/log/journal/*

and reboot.


See also bug #967521 for other apparently related side-effects (like slow/failed boots).

Proposed as a Blocker for 20-beta by Fedora user scorpionit using the blocker tracking app because:

 Does not respect the following criteria

1. Desktop shutdown, reboot, logout
(http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Desktop_shutdown.2C_reboot.2C_logout)

2. Desktop panel 
(http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Desktop_panel)

Discussed in 2013-10-31 Go/No-Go meeting [1]. Voted as a RejectedBlocker. This bug has been around for a long time, has reasonable workarounds and does not appear to be hitting with much consistency.

[1] http://meetbot.fedoraproject.org/meetbot/meetbot/fedora-meeting-2/2013-10-31/

My impression is the bug is specific to the KDE spin, and I think all the workarounds mask a larger, underlying issue. I have recently changed the journald storage setting to volatile and that actually fixes not only this issue, but also some significantly long hangs on boot. Just my two cents.

I am experiencing this issue as well with FC19 - I have not used FC20 yet. Initially in FC19 (and also in previous versions) it only occurred once in a while and a reboot would seem to correct it. Lately though, this issue has been occurring for me with a MUCH greater frequency than it ever had, or has with any other previous version of Fedora. And now, once it occurs, the simple reboot does nothing to address it.

I can try to change the journald storage settings to correct this, as mentioned above, but then I have to roll that change out to all other systems and maintain it with any new systems brought online. Also, would it persist a journald update? This solution is not ideal, for obvious reasons. This needs to be corrected on the distribution side in order to make KDE stable - otherwise I'm going to have to fallback to XFCE or some other desktop environment.

test with rm -rf /tmp/*

test with rm -rf /tmp/* and reboot

when not start: killall ksmserver and  re-login

This isn't a solution but help

In reply to Jeremy Petersen from comment #108)
> Estoy experimentando este problema, así como con FC19 - No he utilizado FC20
> todavía. Inicialmente, en FC19 (y también en versiones anteriores), sólo
> ocurrió una vez en un tiempo y un reinicio parece corregirlo. Últimamente,
> sin embargo, este tema ha estado ocurriendo por mí con una frecuencia mucho
> mayor de lo que nunca tuvo, ni tiene con cualquier otra versión anterior de
> Fedora. Y ahora, una vez que ocurre, el simple reinicio no hace nada para
> abordarlo. Puedo tratar de cambiar la configuración de almacenamiento
> journald para corregir esto, como se mencionó anteriormente, pero luego
> tengo que rodar que el cambio a todos los demás sistemas y mantener con los
> nuevos sistemas puestos en línea. Además, sería persistir una actualización
> journald? Esta solución no es ideal, por razones obvias. Esto debe ser
> corregido en el lado de la distribución con el fin de hacer que KDE estable
> - de lo contrario voy a tener que retroceder a XFCE u otro entorno de
> escritorio.

You should try #93 solution. I have tried it again but in my other machine (when this issue appeared intermitently) and also works perfectly. I haven't tried Rex Dieter solution but I think that scotvalen solution is less invasive (from my ignorance).

I had not tried the scottvalen approach yet, simply because it seemed like the more involved choice - at least to determine what needs to be done/changed. 

The Rex Dieter solution of just clearing out the /var/log/journal and rebooting has been working for me when the issue is encountered. I also have not tried the other change Rex recommended (to the journald config) yet. I am simply correcting the issue as it happens for now.


For the scottvalen solution in #93, below is the result of the grep on my system...

$ grep phase /usr/share/autostart/*
/usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
/usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1

So, given this, would I just be changing ...nepomukserver.desktop:X-KDE-autostart-phase=1 to '2', or is there something else I'm missing?

Umh, I didn't change it and worked, so I wouldn't change it.

It seems that the files that really must be changed are:

/usr/share/autostart/kaddressbookmigrator.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/kgpg.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/kmix_autostart.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-autostart-phase=2

On my system, none of the 5 files you listed here have any 'X-KDE-autostart-phase' parameter in them currently. Are you suggesting that I manually edit all five of these files to add these in? If so, then I will probably just stick with my current workaround until an official solution can be implemented.

This 5 files are which must be edited for KDE start works.Sorry.

(In reply to Jeremy Petersen from comment #114)
> On my system, none of the 5 files you listed here have any
> 'X-KDE-autostart-phase' parameter in them currently. Are you suggesting that
> I manually edit all five of these files to add these in? If so, then I will
> probably just stick with my current workaround until an official solution
> can be implemented.

Indeed, that's the suggestion. However, if your current workaround works, stick to it (, but I don't know whether setting "volatile" has negative effects or not).

I have not tried the "volatile" solution. I am only fixing the problem (over and over again) as it comes happens. 

All I do to get it to start properly is: 

rm -rf /var/log/journal/* && shutdown -r now

The problem is it has to be done over and over again, as it seems like every time I boot the system now it has this issue anew.

My "workaround" stopped working, and the journald.conf change did nothing either.

I went ahead and updated the five files (in #113 above) and at least have a working KDE now.

I found that adding that to kmix_autostart.desktop made the actual kmix window (not drop-down) pop-up on login. I removed the edit from this one file and everything seems to start correctly now.

I will use this as the workaround and hope it keeps working, but think this bug is somewhat of a showstopper, personally.

I have also tried various changes to the journal system, all without any affect. Tried the "volatile" change to the config file this morning, and that changed nothing.

Interestingly, I am having these troubles on a larger, faster machine, with SSD. I also have another older laptop with only a Centrino Dual processor, 2M memory and an SSD, and that machine never has this problem. My last machine is in between the others performance wise, but has an older SATA II hard disk. It has troubles almost all the time as well.

(In reply to Jeremy Petersen from comment #118)
> I found that adding that to kmix_autostart.desktop made the actual kmix
> window (not drop-down) pop-up on login.

Take a look at comment #98 to solve the kmix pop-up solution.

> I will use this as the workaround and hope it keeps working, but think this
> bug is somewhat of a showstopper, personally.

You're right!

(In reply to Al from comment #119)
> I have also tried various changes to the journal system, all without any
> affect. Tried the "volatile" change to the config file this morning, and
> that changed nothing.
> 
> Interestingly, I am having these troubles on a larger, faster machine, with
> SSD. I also have another older laptop with only a Centrino Dual processor,
> 2M memory and an SSD, and that machine never has this problem.

Indeed! That's exactly what happens to me: a slower laptop with AMD Athlon doesn't experience the issue. All fast systems I have, do experience the issue.

(In reply to Elias Vanderstuyft from comment #121)
> (In reply to Al from comment #119)
> > I have also tried various changes to the journal system, all without any
> > affect. Tried the "volatile" change to the config file this morning, and
> > that changed nothing.
> > 
> > Interestingly, I am having these troubles on a larger, faster machine, with
> > SSD. I also have another older laptop with only a Centrino Dual processor,
> > 2M memory and an SSD, and that machine never has this problem.
> 
> Indeed! That's exactly what happens to me: a slower laptop with AMD Athlon
> doesn't experience the issue. All fast systems I have, do experience the
> issue.

Are the machines that are working well 32-bit, or 64-bit? All my stuff is 64-bit, and it's all broken.

All my machines are 64-bit installations, from the exact same Fedora-Live-KDE-x86_64-19-1.iso distribution. The packages installed are a little different, with my main system (obviously) having the most.

(In reply to scottvalen from comment #122)
> (In reply to Elias Vanderstuyft from comment #121)
> > (In reply to Al from comment #119)
> > > I have also tried various changes to the journal system, all without any
> > > affect. Tried the "volatile" change to the config file this morning, and
> > > that changed nothing.
> > > 
> > > Interestingly, I am having these troubles on a larger, faster machine, with
> > > SSD. I also have another older laptop with only a Centrino Dual processor,
> > > 2M memory and an SSD, and that machine never has this problem.
> > 
> > Indeed! That's exactly what happens to me: a slower laptop with AMD Athlon
> > doesn't experience the issue. All fast systems I have, do experience the
> > issue.
> 
> Are the machines that are working well 32-bit, or 64-bit? All my stuff is
> 64-bit, and it's all broken.

All are 64-bit, the AMD Athlon also (and doesn't experience the problem.)

*** Bug 1028425 has been marked as a duplicate of this bug. ***

Got manifestation of this error on 32-bit system with non-Nvidia video (Fedora 19, KDE, fresh install on laptop, Core Duo 2GHz/2Gb RAM/Intel 945GM/GMS video)

Recent updates changed something, now I get some error when starting kmix manually.

$ kmix
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)

The last upgrades removed changes in autostart files and now the error has returned.

Now, I  will test with edit only /usr/share/autostart/polkit-kde-authentication-agent-1.desktop

Well... polkit-kde-authentication-agent-1.desktop and xsettings-kde.desktop didn't modify because packages which provide them haven't upgraded :P

So, I will try edit only kmix_autostart.desktop

modify only kmix_autostart.desktop doesn't work. :(

Today I have experimented this bug with all files modified :/ In the last session I made some configuration changes in KDE.

(In reply to carlos.rca185 from comment #131)
> Today I have experimented this bug with all files modified :/ In the last
> session I made some configuration changes in KDE.

So the fix from comment #93 doesn't work anymore?

So far I have not had another problem, and the computer who experienced the bug in all KDE starts, works for the moment . Just seems that there may be times when even with this configuration, you can also fail.


_________________________________________
This is the original message in Spanish, translated into english by google translator. Sorry, but I'm not english speaker:

De momento no he tenido otro problema, y el ordenador que experimentaba el bug en todos los inicios no falla de momento. Simplemente, parece que puede haber ocasiones en las que incluso con esta configuración, también puede fallar.

(In reply to carlos.rca185 from comment #133)
> So far I have not had another problem, and the computer who experienced the
> bug in all KDE starts, works for the moment . Just seems that there may be
> times when even with this configuration, you can also fail.
> 
> 
> _________________________________________
> This is the original message in Spanish, translated into english by google
> translator. Sorry, but I'm not english speaker:
> 
> De momento no he tenido otro problema, y el ordenador que experimentaba el
> bug en todos los inicios no falla de momento. Simplemente, parece que puede
> haber ocasiones en las que incluso con esta configuración, también puede
> fallar.

Even if it only fails for once, it means that the problem is not solved.

I was told that the other computer is not working (it isn't mine) so the patch does not work.

__________________________________
This is the original message in Spanish, translated into english by google translator. Sorry, but I'm not english speaker:

Me han dicho que el otro ordenador ya no funciona (no es mio) así que el parche ya no funciona.

Fyi... This issue has not returned for me following the most recent round of patches. Here are the phase lines from my autostart files as they stand currently:

[jeremy@localhost ~]$ grep phase /usr/share/autostart/*
/usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-autostart-phase=2
/usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1
/usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1

(In reply to Jeremy Petersen from comment #136)
> Fyi... This issue has not returned for me following the most recent round of
> patches. Here are the phase lines from my autostart files as they stand
> currently:
> 
> [jeremy@localhost ~]$ grep phase /usr/share/autostart/*
> /usr/share/autostart/kalarm.autostart.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/konqy_preload.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/korgac.desktop:X-KDE-autostart-phase=2
> /usr/share/autostart/krunner.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/nepomukserver.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/plasma-desktop.desktop:X-KDE-autostart-phase=0
> /usr/share/autostart/polkit-kde-authentication-agent-1.desktop:X-KDE-
> autostart-phase=2
> /usr/share/autostart/restore_kmix_volumes.desktop:X-KDE-autostart-phase=1
> /usr/share/autostart/xsettings-kde.desktop:X-KDE-autostart-phase=1

I've got exactly the same output.
BUT after the updates, the issue HAS returned... (so with same settings what grep is listing)

could someone please confirm whether the problem is gone with the workaround (disable persistent journal logging, set in /etc/systemd/journald.conf: Storage=volatile) ?

Thanks

That seems to help for some (all machines @ my site, for example), but not for others, if you read the history of this bug.

I'm not currently using Fedora KDE Spin anymore, so I can't really test this. However, I"m not having any issues in Arch Linux with KDE, which uses journald exclusively for logging. Journal storage is set to auto there. Does setting "auto" result in this bug as well, or only "persistent"?

My understanding is that auto only creates persistent logs if /var/log/journal already exists. Is that correct? Journal logs are being stored there on Arch, and boot time is still quite fast. 

I'm still not clear on why the journal storage setting is a problem for KDE specifically. Could someone please elaborate. Does it relate to redundant logging with rsyslog?

disabling persistent journal logging, the bug shows itself less frequently but it's not really fixed.

giving rm -rf /var/tmp/* before shutdown, the bug doesn't show itself in the following boot

(In reply to Ngo Than from comment #138)
> could someone please confirm whether the problem is gone with the workaround
> (disable persistent journal logging, set in /etc/systemd/journald.conf:
> Storage=volatile) ?
> 
> Thanks

I'm using "Storage=volatile", and the issue remains.

(re comment #127):
> Object::connect: No such signal
>   org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
> Object::connect: No such signal
>   org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)

This is a different issue, an API change in upower. It is not related to this bug.

*** Bug 1030726 has been marked as a duplicate of this bug. ***

I have a similar problem.
Symptom:
1) Can not shutdown, reboot.
2) No kmix start at startup
3) No application launch at startup that KDE
The problem goes away after restarting Displey Manager(systemctl restart kdm.service)
Change DM not solve the problem

(In reply to Murzik2142 from comment #145)
> I have a similar problem.
> Symptom:
> 1) Can not shutdown, reboot.
> 2) No kmix start at startup
> 3) No application launch at startup that KDE
> The problem goes away after restarting Displey Manager(systemctl restart
> kdm.service)
> Change DM not solve the problem


Yet there is sometimes a bug in the widget desktop:
Can not start process Unable to access klauncher: Did not receive a realy. Possible causes include: the remote application did not send a reaply, the massage bus security policy blocked the reaply, the reply timeout expired, or the network connection was broken

(In reply to Murzik2142 from comment #146)
> (In reply to Murzik2142 from comment #145)
> > I have a similar problem.
> > Symptom:
> > 1) Can not shutdown, reboot.
> > 2) No kmix start at startup
> > 3) No application launch at startup that KDE
> > The problem goes away after restarting Displey Manager(systemctl restart
> > kdm.service)
> > Change DM not solve the problem
> 
> 
> Yet there is sometimes a bug in the widget desktop:
> Can not start process Unable to access klauncher: Did not receive a realy.
> Possible causes include: the remote application did not send a reaply, the
> massage bus security policy blocked the reaply, the reply timeout expired,
> or the network connection was broken

Yes, that happens if you start a launcher too early after login (when this bug is active.)

For those struggling with virt-manager, this post helped me: http://niranjanmr.wordpress.com/2013/03/20/auth-libvirt-using-polkit-in-fedora-18/

In summary,

# cat 10.virt.rules 
        polkit.addRule(function(action, subject) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        var now = new Date();
        polkit.log("now=" + now)
        if ((action.id == "org.libvirt.unix.manage" || "org.libvirt.unix.monitor") && subject.isInGroup("virt")) {
        return polkit.Result.YES;
        }
        return null;
        });

And add your used to virt group (add the group too if needed).

I'm using virt-manager to connect to a remote host (on which I did the modifications above) and I was having the same polkit issue. As I have no graphical environment on this local host, seems I cannot have any authentication agent running (all of them requires X??), so this change came in handy.

HTH!

Please DO NOT use the above snippet as posted, it contains incorrect JavaScript syntax!

Here's a corrected version:
        polkit.addRule(function(action, subject) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        var now = new Date();
        polkit.log("now=" + now)
        if ((action.id == "org.libvirt.unix.manage" || action.id == "org.libvirt.unix.monitor") && subject.isInGroup("virt")) {
        return polkit.Result.YES;
        }
        return null;
        });

(and allowing individual actions is not really a suitable workaround for polkit-kde-authentication-agent-1 not getting started; it's fine if you really want to always allow libvirt without a password prompt, but it doesn't solve the real issue at hand here)

Aye, thanks for the new script!

Fully agreed that this is far from a suitable workaround. It's like using a hammer to put a screw in, but if you are in a rush like I was, it may very well be useful ;)

This BZ is 5 months open now. Any idea on when a real fix will come up?

Updating to this build http://koji.fedoraproject.org/koji/buildinfo?buildID=482571 fixed the issue on a clear Fedora 20 installation.
Returning to systemd-208-6.x86_64.fc20 doesn't expose the behavior again though.

*** Bug 1032921 has been marked as a duplicate of this bug. ***

As per my comment in https://bugzilla.redhat.com/show_bug.cgi?id=1032921 , I have hit this from a clean F20 Final TC5 KDE x86_64 live install on the second boot post-install, with systemd-208-8.x86_64.fc20 installed the whole time (it's part of TC5) and with KDM as the login manager. Seems pretty clear now that this is not caused by https://bugzilla.redhat.com/show_bug.cgi?id=1006386 or by sddm .

Finally this bug is accepted as a blocker.

it was accepted a week or two ago, but as https://bugzilla.redhat.com/show_bug.cgi?id=1032921 . that status has transferred to this bug now we closed that as a dupe of this.

So one thing that would be interesting to debug:

gdb --pid `pidof ksmserver`
break KSMServer::logout(int,int,int)
c

and in another Konsole tab/window:

qdbus org.kde.ksmserver /KSMServer logout 0 2 2

(The parameters stand for ShutdownConfirmNo, ShutdownTypeHalt, ShutdownModeForceNow.)

1. Does that trigger the breakpoint in GDB? If not, ksmserver is not listening to D-Bus, which would explain the bug (but of course then we'd need to figure out WHY it's not listening).
2. If yes, try single-stepping it in GDB to see what happens. We really need to know where it fails to shut down.

(In reply to Kevin Kofler from comment #157)
> So one thing that would be interesting to debug:
> 
> gdb --pid `pidof ksmserver`
> break KSMServer::logout(int,int,int)
> c
> 
> and in another Konsole tab/window:
> 
> qdbus org.kde.ksmserver /KSMServer logout 0 2 2
> 
> (The parameters stand for ShutdownConfirmNo, ShutdownTypeHalt,
> ShutdownModeForceNow.)
> 
> 1. Does that trigger the breakpoint in GDB? If not, ksmserver is not
> listening to D-Bus, which would explain the bug (but of course then we'd
> need to figure out WHY it's not listening).
> 2. If yes, try single-stepping it in GDB to see what happens. We really need
> to know where it fails to shut down.

Not near a machine showing this bug but i am pretty sure the dbus message is getting there but if startup is not complete then KSMServer will just keep setting a timer and waiting to see if startup is complete [1].

[1] - kde-workspace/ksmserver/shutdown.cpp:104

(In reply to john5342 from comment #80)
> The next thing i am going to try is some rebuilds of kdelibs and
> kde-workspace with some more debug output to help narrow it down but i am
> halfway around the world at the moment so it's going to have to wait until
> the weekend at least unless somebody beats me to it.

I was kindly reminded today that i never actually reported back on this one. Unfortunately, just like with my dbus-monitor sniffing before, i couldn't reproduce with debug statements in place. I also had the same problem with gdb.

Unfortunately i lost my previous work in a crash but i am currently in the process of re-creating some patches (just extra kWarning statements) to try and narrow things down.

kde-workspace-4.11.3-6.fc20,kdelibs-4.11.3-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kde-workspace-4.11.3-6.fc20,kdelibs-4.11.3-6.fc20

kde-workspace-4.11.3-6.fc19, kdelibs-4.11.3-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kdelibs-4.11.3-6.fc19,kde-workspace-4.11.3-6.fc19

Folks, the updates contain changes that _might_ plausibly fix the bug, but we're not 100% sure by any means that they do. So it'd really help if people who can quite reliably reproduce the bug could try with the updated packages and let us know how things go. Thanks!

(In reply to Kevin Kofler from comment #157)
> So one thing that would be interesting to debug:
> 
> gdb --pid `pidof ksmserver`
> break KSMServer::logout(int,int,int)
> c
> 
> and in another Konsole tab/window:
> 
> qdbus org.kde.ksmserver /KSMServer logout 0 2 2
> 
> (The parameters stand for ShutdownConfirmNo, ShutdownTypeHalt,
> ShutdownModeForceNow.)
> 
> 1. Does that trigger the breakpoint in GDB? If not, ksmserver is not
> listening to D-Bus, which would explain the bug (but of course then we'd
> need to figure out WHY it's not listening).
> 2. If yes, try single-stepping it in GDB to see what happens. We really need
> to know where it fails to shut down.

(Info: I did not apply kde-workspace-4.11.3-6.fc20,kdelibs-4.11.3-6.fc20 yet.)

This morning the issue appeared (that means 'qdbus org.kde.ksmserver /KSMServer logout 0 2 2' does not trigger shutdown), so I did what you asked, and option 2.) is true.

I did 2 attempts:
    - Stepping manually (too slow, so DBus timed out, probably rendering this attempt useless)
    - Continuing (not able to see what's happening)
I saved the debug log and will attached it.

Is there a way to step automatically (=faster, so DBus would not time out) and save the debug log to a file?

Created attachment 833866 [details]
Gdb log of ksmserver when issuing shutdown command

See comment #163 for more details.

Setting out of MODIFIED. The referenced update doesn't fix the bug, it only adds debugging code. My attempt at fixing it by increasing the timeout doesn't seem to have helped either, unfortunately.

(In reply to Kevin Kofler from comment #157)
> So one thing that would be interesting to debug:
> 
> gdb --pid `pidof ksmserver`
> break KSMServer::logout(int,int,int)
> c
> 
> and in another Konsole tab/window:
> 
> qdbus org.kde.ksmserver /KSMServer logout 0 2 2
> 
> (The parameters stand for ShutdownConfirmNo, ShutdownTypeHalt,
> ShutdownModeForceNow.)
> 
> 1. Does that trigger the breakpoint in GDB? If not, ksmserver is not
> listening to D-Bus, which would explain the bug (but of course then we'd
> need to figure out WHY it's not listening).
> 2. If yes, try single-stepping it in GDB to see what happens. We really need
> to know where it fails to shut down.

OK, this time, I think I got lucky:
I managed to get the debug log without D-Bus timing out (~ 20s)! (I did so by stepping using 'next' instead of 'step')

I caught the point where the D-Bus message is sent, and the point where everything gets stationary again (the end of the log).

I'll post the attachment in the next comment.

Created attachment 833895 [details]
Gdb log of ksmserver when issuing shutdown command (attempt 3)

Gdb log of ksmserver when issuing shutdown command (attempt 3)
This attempt is probably successful.

See comment #166 for more details.

I hit this bug against last night in a F20 VM - it's been working fine for the last few days, so it's not repeatable; however one thing I did notice was that polkit-kde-authentication-agent-1 was running, so it's not the same as the stuff we were seeing a few months back where that missing was the culprit.

I did start attaching the gdb but then made the fatal mistake of pasting
the qdbus line into the wrong window and shutting down the host :-(

Dave

Comment on attachment 833895 [details]
Gdb log of ksmserver when issuing shutdown command (attempt 3)

So the problem there is that ksmserver thinks it is still starting up and thus delays the shutdown. The real bug is in the autostart phase.

On the advice of Kevin Kofler in IRC, I created a file qt-no-glib.sh in /etc/profile.d/ containing:

QT_NO_GLIB=1
export QT_NO_GLIB

With this file present, the bug is not in evidence. The 60s delay on autostart that was instituted by Rex Dieter in kdelibs-4.11.3-7.fc20.x86_64 is also not present - the system starts up immediately (systemd-analyze says 21s)

I've rebooted multiple times since the update to kdelibs -7 and the addition of the qt-no-glib.sh. As stated, with qt-no-glib in place, the bug  is not present. When the file is removed, the bug returns.

Here are the .xsession-errors logs produced by the latest updates to kdelibs and/or kde-workspace:

without the qt-no-glib.sh file, bug present:

http://paste.fedoraproject.org/59857/64508301
http://paste.fedoraproject.org/59916/86484323
http://paste.fedoraproject.org/59919/88374138

With qt-no-glib.sh in place, bug not in evidence:

http://paste.fedoraproject.org/59912/38648039
http://paste.fedoraproject.org/59915/48391113
http://paste.fedoraproject.org/59921/86488643

One other "Feature" of the bug I discovered - when it is active and the shutdown/restart/logout buttons in the panel are not working, the physical power button of the machine also does not initiate the shutdown process. Since the sleep and hibernate functions *do* work with the bug active, the physical sleep button on the laptop works.

So it looks like this only happens with Qt's GLib event loop integration, which is unfortunately needed for some applications (which have to interoperate with GLib-event-driven libraries) to work properly, so just turning it off is not an option.

I conclude that this must be a regression in glib2 ≥ 2.36:
* Fedora 18, which worked, has glib2-2.34.
* Fedora 19, where this started breaking, has glib2-2.36.
* Qt 4 is the same between Fedora 18 and 19.
* The bug also happened with KDE 4.10 on F19, the same KDE F18 has.
* There have been some tweaks to the GLib mainloop in 2.36.

(As for that timeout value in KLauncher, we will revert it from 60 to 30 seconds, given that increasing it hasn't helped.)

Reassigning to glib2 based on my findings above:

> So it looks like this only happens with Qt's GLib event loop integration, which
> is unfortunately needed for some applications (which have to interoperate with
> GLib-event-driven libraries) to work properly, so just turning it off is not an
> option.
>
> I conclude that this must be a regression in glib2 ≥ 2.36:
> * Fedora 18, which worked, has glib2-2.34.
> * Fedora 19, where this started breaking, has glib2-2.36.
> * Qt 4 is the same between Fedora 18 and 19.
> * The bug also happened with KDE 4.10 on F19, the same KDE F18 has.
> * There have been some tweaks to the GLib mainloop in 2.36.

(Sorry, I had meant to do that right when posting comment #171 above.)

there's about five pages worth of git log between 2.36 and 2.38 :/ sounds like we'll need an expert to track it down.

It would be interesting to know if this affected Fedora 19 Beta. It's kind of notable that the first recorded report of this is from July - I might have expected there to be reports from earlier during F19 testing, given the number of people who seem to have hit it later. So it's possible, I guess, that it broke *during* the glib2 2.38 cycle. 19 Beta has an older glib2 than 19 Final and 20, but still a 2.38 one, so if it didn't affect that, we can narrow down the search a bit.

So, can people who can reproduce this reliably test if it affects https://www.happyassassin.net/extras/Fedora-Live-KDE-x86_64-19-Beta-1.iso , if at all possible? That's F19 KDE desktop x86_64 live beta. It'd be useful information. Thanks!

sigh, i keep saying 2.36 and 2.38 when I mean 2.34 and 2.36.

https://bugzilla.gnome.org/show_bug.cgi?id=711090 is about fixing a deadlock-causing mainloop regression that got introduced at around that time...

note: if the deadlocking process has a zombie child attached to it, then it's almost certainly caused by the above issue... otherwise, (probably) not.

I noticed that the failed logs all fail at the same place, after starting nepomukserver (and before starting krunner, but it doesn't even get there, so I don't think krunner can be blamed).

Kevin has done a build which disables klauncher's use of the glib mainloop. If those affected by this issue can test with this build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6270676

(ARM is still building as I type this, but you can grab the files for i686 or x86_64) and let us know if it works, that'd be great. Thanks!

I tried Fedora 19 beta, booted few times. I did not see this bug. (since this bug does not happen every time the bug still might be in the beta, but to me it looks like beta is working)

(In reply to Adam Williamson from comment #179)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6270676

Tested installing this onto a computer that was hit with the bug. Result is exactly the same as with changing from systemd-208-6 to systemd-208-8 as per Comment 152:
It fixes the issue for next bootups but when I return to kdelibs-4.11.3-1 which are shipped with the installed image, the problem is gone too.

martin: riku: how often do you usually hit the bug?

I tested the new kdelibs build in the computer which always has the issue and it works correctly. I rebooted 6 times and the issue hasn't appeared.

The only thing that get my attention is that kmix before patch and when the bug isn't present, started at same time that the panel, now it's delayed a bit.

I don't downgraded to kdelibs of the repositories.

With kdelibs-4.11.3-8.fc20.x86_64, I could not reproduce the problem. It seems that Kevin's last update worked around the issue in glib. Rex also wrote an update to qtwebkit that may or may not be related, but that's for a different bug (it was only discovered while testing this one).

Here are my (very brief) logs:

Boot #7 at 202012082013UTC
qt-no-glib.sh not used
bug present
.xsession-errors: http://paste.fedoraproject.org/60004/38653410
ps aux: http://paste.fedoraproject.org/60005/13865344

Boot #8 at 150512092013UTC
qt-no-glib.sh not used, kdelibs-4.11.3-8.fc20.x86_64 update applied
successful
.xsession-errors: http://paste.fedoraproject.org/60191/66016931
ps aux: http://paste.fedoraproject.org/60192/60179713

Boot #9 at 153512092013UTC
qt-no-glib.sh not used, kdelibs-4.11.3-8.fc20.x86_64 update applied
successful
.xsession-errors: http://paste.fedoraproject.org/60201/03379138
ps aux: http://paste.fedoraproject.org/60202/86603405

Boot #9 at 154312092013UTC
qt-no-glib.sh not used, kdelibs-4.11.3-8.fc20.x86_64 update applied
successful
.xsession-errors: http://paste.fedoraproject.org/60205/86604043
ps aux: http://paste.fedoraproject.org/60206/04061138

boot #10 at 163012092013UTC
qt-no-glib.sh not used, kdelibs-4.11.3-8.fc20.x86_64 update applied
nvidia proprietary drivers removed, using nouveau
successful
.xsession-errors: http://paste.fedoraproject.org/60215/66068211
ps aux: http://paste.fedoraproject.org/60216/06841138

kdelibs-4.11.3-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2013-22657/kdelibs-4.11.3-9.fc20

kdelibs-4.11.3-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to Adam Williamson from comment #182)
> martin: riku: how often do you usually hit the bug?

Even though it's closed, just to fill in the gaps: I had to reinstall the whole system to reproduce the bug but I hit it in about every fifth installation. After doing anything to get rid of the issue, I couldn't reproduce it anymore in no way, reverting to previous configuration didn't do anything.
When the update hits the repositories, I'll try a few installs again to see.

Will there also be an update for Fedora 19?

Yes, 
https://admin.fedoraproject.org/updates/FEDORA-2013-23008/kdelibs-4.11.3-9.fc19

in updates-testing now.  Please do test, if you're able, and give feedback.  thanks.

kdelibs-4.11.3-9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

I just updated my system, then reboot. No change observed, still gives me the same delay after logging in before kmix and klipper show up - on this system that is about 10 to 15 seconds.  ;-{

delay is sometimes not too abnormal, but this bug was about autostart items not starting *at all*.

I rebooted my system 3 times with success, that means:
I was able to shutdown the system in the appropriate way.

However: on the second boot, I also got this delay of about 10 to 15 seconds, AND something did not startup/initialise correctly:
Some of the desktop effects behaved otherwise than normal:
Normally, clicking the 'Start'/ApplicationLauncher button, the menu *slides* in, but this time, it just *fades* in. That means some desktop effect did not load properly.

I forgot to mention that I removed "/etc/xdg/autostart/pulseaudio.desktop" and "/etc/xdg/autostart/pulseaudio-kde.desktop", so probably those can't be blamed of causing the 10 to 15 seconds delay in the second boot of my previous comment.