Bug 983110 - (heisenbug) several autostart apps (e.g. polkit-kde, kmix) and logout/shutdown countdown fails
several autostart apps (e.g. polkit-kde, kmix) and logout/shutdown countdown ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kdelibs (Show other bugs)
19
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
AcceptedBlocker
:
: 877215 986613 991845 994647 1009891 1028425 1030726 1032921 (view as bug list)
Depends On: 967521
Blocks: F20FinalBlocker 986613
  Show dependency treegraph
 
Reported: 2013-07-10 10:09 EDT by Martin
Modified: 2014-11-17 10:47 EST (History)
60 users (show)

See Also:
Fixed In Version: kdelibs-4.11.3-9.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-10 01:57:58 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)
the session error file (12.79 KB, text/plain)
2013-08-20 13:11 EDT, ycollet
no flags Details
Gdb log of ksmserver when issuing shutdown command (72.93 KB, text/plain)
2013-12-07 06:20 EST, Elias Vanderstuyft
no flags Details
Gdb log of ksmserver when issuing shutdown command (attempt 3) (10.14 KB, text/plain)
2013-12-07 09:13 EST, Elias Vanderstuyft
no flags Details
Comment (104.05 KB, text/plain)
2013-07-11 10:50 EDT, Martin
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 325155 None None None Never
KDE Software Compilation 328571 None None None Never

  None (edit)
Description Martin 2013-07-10 10:09:24 EDT
Description of problem:
Unable to connect to libvirt in KDE. Error after Virt-manager startup.

authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available

Version-Release number of selected component (if applicable):
polkit-0.111-2.fc19.x86_64
polkit-kde-0.99.1-1.20130311git.fc19.x86_64
polkit-qt-0.103.0-7.fc19.x86_64
virt-manager-0.10.0-1.fc19.noarch
libvirt-client-1.0.5.2-1.fc19.x86_64

How reproducible:
always

Steps to Reproduce:
1. Login to KDE
2. Run Virt-Manager

Actual results:
This error causes Virt-manager is not usable in KDE.

Expected results:
Virt-Manager starts and asks for password to gain permission to handle libvirt resources, like in Gnome session.

Additional info:
Unable to connect to libvirt.

authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1002, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 984, in _try_open
    flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available.
Comment 1 Rex Dieter 2013-07-10 13:04:15 EDT
Is polkit-kde-authentication-agent-1 running in your session?

It should be, see 
/usr/share/autostart/polkit-kde-authentication-agent-1.desktop
Comment 2 Martin 2013-07-11 07:59:53 EDT
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
Comment 3 Martin Bříza 2013-07-11 08:04:05 EDT
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.
Comment 4 Rex Dieter 2013-07-11 08:33:16 EDT
Not polkitd, I asked about polkit-kde-authentication-agent-1 process
Comment 5 Martin 2013-07-11 08:59:44 EDT
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".
Comment 6 Rex Dieter 2013-07-11 09:07:08 EDT
OK, reassigning to selinux-policy for advice/guidance at this point.
Comment 7 Martin 2013-07-11 09:37:39 EDT
Note: I can't reproduce it with KDM, but when I switch back to GDM and can still reproduce it.
Comment 8 Miroslav Grepl 2013-07-11 10:21:19 EDT
Could you re-test it in permissive mode and then run

# ausearch -m avc,user_avc -ts recent
Comment 9 Martin 2013-07-11 10:26:03 EDT
----
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=?'
Comment 10 Miroslav Grepl 2013-07-11 10:44:54 EDT
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
Comment 11 Martin 2013-07-11 10:50:34 EDT
Created attachment 915731 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 12 Miroslav Grepl 2013-07-11 11:47:44 EDT
I will need to try to reproduce it. So KDE+virt-manager, right?
Comment 13 Martin 2013-07-11 11:49:25 EDT
KDE + GDM. Look if polkit-kde-authentication-agent-1 process is running.
Comment 16 Miroslav Grepl 2013-07-11 16:06:13 EDT
Martin,
is this working for you in permissive mode?
Comment 17 Miroslav Grepl 2013-07-12 02:16:28 EDT
It works for me. I am able to start Virtual Machine Manager without problems.
Comment 18 Michael Treitel 2013-07-14 22:25:46 EDT
(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
Comment 19 Martin 2013-07-15 04:45:26 EDT
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.
Comment 20 Miroslav Grepl 2013-07-15 05:05:26 EDT
I use enforcing mode by default.
Comment 21 Miroslav Grepl 2013-07-15 08:34:13 EDT
Michael,
could you try to execute

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

and re-test it?
Comment 22 Michael Treitel 2013-07-15 12:43:30 EDT
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
Comment 23 Daniel Walsh 2013-07-15 17:49:26 EDT
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.
Comment 24 Michael Treitel 2013-07-15 21:00:52 EDT
(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?
Comment 25 brian 2013-07-25 23:12:05 EDT
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?
Comment 26 Miroslav Grepl 2013-07-26 02:46:18 EDT
If it does not work in permissive mode then it is not a SELinux issue.
Comment 27 Martin Bříza 2013-08-01 04:57:33 EDT
To everybody able to reproduce the bug: With which display manager does this happen, please?
Comment 28 Martin 2013-08-01 09:29:31 EDT
I can reproduce it only with GDM.
Comment 29 Michael Treitel 2013-08-01 14:27:54 EDT
I can reproduce this in KDM — KDE Display Manager
Comment 30 Michael Treitel 2013-08-01 14:28:34 EDT
I can reproduce this in KDM — KDE Display Manager
Comment 31 Daniel Walsh 2013-08-01 21:33:30 EDT
In permissive mode?
Comment 32 brian 2013-08-01 23:13:00 EDT
KDE for me.
Comment 33 brian 2013-08-01 23:14:49 EDT
For my symptoms, but #986613, yes I it happens in permissive mode as well as enforcing mode.
Comment 34 Martin Bříza 2013-08-05 04:00:04 EDT
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.
Comment 35 Kevin Kofler 2013-08-05 17:34:52 EDT
*** Bug 991845 has been marked as a duplicate of this bug. ***
Comment 36 Diesel 2013-08-06 12:38:16 EDT
reporting : GDM seems to fix the problem , been using it for 2 days and no sign of trouble
Comment 37 Diesel 2013-08-06 16:24:54 EDT
reporting back : gdm does not fix the problem , problem is back again , and i am sick of this bug !
Comment 38 Martin Bříza 2013-08-07 09:26:24 EDT
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.
Comment 39 Martin Bříza 2013-08-07 09:47:34 EDT
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.
Comment 40 Martin Bříza 2013-08-08 03:36:23 EDT
*** Bug 986613 has been marked as a duplicate of this bug. ***
Comment 41 Diesel 2013-08-09 07:48:15 EDT
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 ?
Comment 42 Rex Dieter 2013-08-09 07:59:04 EDT
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
Comment 43 Clay 2013-08-09 19:13:22 EDT
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).
Comment 44 Rex Dieter 2013-08-09 19:41:40 EDT
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?
Comment 45 Clay 2013-08-10 03:43:54 EDT
(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 .
Comment 46 Kevin Kofler 2013-08-11 13:20:25 EDT
*** Bug 994647 has been marked as a duplicate of this bug. ***
Comment 47 Riku Seppala 2013-08-14 03:22:00 EDT
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.
Comment 48 ycollet 2013-08-15 03:17:36 EDT
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
Comment 49 Lukas Middendorf 2013-08-15 03:29:28 EDT
The problem with kde-settings-kdm is bug #989145 . Should be unrelated to this bug.
Comment 50 Martin Bříza 2013-08-19 06:10:22 EDT
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.
Comment 51 ycollet 2013-08-19 06:13:54 EDT
Thanks for the information. I already did that and you were right, this is not related to this bug.

YC
Comment 52 Fred 2013-08-19 15:51:23 EDT
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.
Comment 53 ycollet 2013-08-19 16:07:03 EDT
I also have a nvidia card but not with the closed source driver.
Comment 54 Martin Bříza 2013-08-20 03:50:02 EDT
Intel graphics card here just for the record...
Comment 55 ycollet 2013-08-20 13:10:37 EDT
I found a .xsession-errors in my home directory.
I attached it to the bug report. Maybe it will help.
Comment 56 ycollet 2013-08-20 13:11:31 EDT
Created attachment 788563 [details]
the session error file
Comment 57 Kevin Kofler 2013-08-20 17:49:52 EDT
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?
Comment 58 Clay 2013-08-20 19:21:52 EDT
There are no .xsession_errors in my testing.
Comment 59 brian 2013-08-20 21:42:03 EDT
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.
Comment 60 ycollet 2013-08-22 01:32:01 EDT
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.
Comment 61 Martin Bříza 2013-08-22 05:08:08 EDT
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.
Comment 62 Riku Seppala 2013-08-22 06:22:16 EDT
After updating selinux-policy from updates-testing it seems to work most of the time. Can't say that it works every time though.
Comment 63 Marcos Terra 2013-08-22 09:38:45 EDT
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...
Comment 64 john5342 2013-09-08 17:43:23 EDT
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.
Comment 65 Rex Dieter 2013-09-19 09:51:07 EDT
*** Bug 877215 has been marked as a duplicate of this bug. ***
Comment 66 Rex Dieter 2013-09-19 09:51:45 EDT
*** Bug 1009891 has been marked as a duplicate of this bug. ***
Comment 67 scottvalen 2013-09-20 20:17:56 EDT
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.
Comment 68 john5342 2013-09-20 21:20:22 EDT
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
Comment 69 James Wilson Harshaw IV 2013-09-21 00:46:31 EDT
Does not work for me. I installed fresh GNOME awhile ago then removed it and installed KDE.
Comment 70 john5342 2013-09-21 18:46:16 EDT
(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
Comment 71 Elias Vanderstuyft 2013-09-22 10:32:29 EDT
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.
Comment 72 Elias Vanderstuyft 2013-09-22 10:33:20 EDT
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.
Comment 73 Al 2013-09-22 12:53:28 EDT
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.
Comment 74 john5342 2013-09-22 12:55:56 EDT
(In reply to Al from comment #73)
> but still no login sound.

That is by design starting with KDE 4.11 i believe.
Comment 75 James Wilson Harshaw IV 2013-09-22 14:34:05 EDT
(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.
Comment 76 Al 2013-09-22 17:34:27 EDT
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.
Comment 77 Elias Vanderstuyft 2013-09-23 07:36:09 EDT
(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'.
Comment 78 Rex Dieter 2013-09-23 13:55:06 EDT
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.
Comment 79 Rex Dieter 2013-09-23 15:37:48 EDT
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.
Comment 80 john5342 2013-09-23 18:23:36 EDT
(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.
Comment 81 David Jones 2013-09-30 22:19:32 EDT
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.
Comment 82 Elias Vanderstuyft 2013-10-01 03:51:45 EDT
(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!
Comment 83 David Jones 2013-10-02 21:59:54 EDT
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.
Comment 84 Rex Dieter 2013-10-03 08:55:02 EDT
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.
Comment 85 Al 2013-10-03 13:53:31 EDT
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.
Comment 86 David Jones 2013-10-03 14:21:20 EDT
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.
Comment 87 carlos.rca185 2013-10-05 18:24:27 EDT
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?
Comment 88 Rex Dieter 2013-10-05 20:46:28 EDT
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?
Comment 89 Elias Vanderstuyft 2013-10-06 08:14:24 EDT
(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)
Comment 90 Al 2013-10-06 10:05:18 EDT
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.
Comment 91 David Jones 2013-10-06 14:22:55 EDT
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
Comment 92 David Jones 2013-10-06 15:03:02 EDT
I managed to reproduce this bug logging into KDE via GDM as well.
Comment 93 scottvalen 2013-10-09 21:19:54 EDT
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.
Comment 94 Dmitry Slivin 2013-10-11 13:19:19 EDT
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.
Comment 95 Elias Vanderstuyft 2013-10-11 17:14:15 EDT
(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'.
Comment 96 carlos.rca185 2013-10-11 17:52:31 EDT
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.
Comment 97 Elias Vanderstuyft 2013-10-13 08:21:20 EDT
(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.
Comment 98 carlos.rca185 2013-10-15 19:27:17 EDT
change the line "exec=kmix" for "exec=kmix --keepvisibility" in /usr/share/autostart/kmix_autostart.desktop solves the problem with kmix window. :)
Comment 99 Elias Vanderstuyft 2013-10-16 15:07:04 EDT
(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 ;)
Comment 100 Denis Kaznadzey 2013-10-22 15:50:19 EDT
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.
Comment 101 carlos.rca185 2013-10-23 14:27:38 EDT
Have you tried the solution in # 93?
Comment 102 Denis Kaznadzey 2013-10-23 17:39:38 EDT
(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.
Comment 103 carlos.rca185 2013-10-27 17:22:32 EDT
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
Comment 104 Rex Dieter 2013-10-27 18:30:04 EDT
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).
Comment 105 Fedora Blocker Bugs Application 2013-10-31 14:31:51 EDT
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)
Comment 106 Mike Ruckman 2013-10-31 14:55:50 EDT
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/
Comment 107 scottvalen 2013-10-31 15:06:39 EDT
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.
Comment 108 Jeremy Petersen 2013-10-31 15:16:00 EDT
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.
Comment 109 Elia Devito 2013-10-31 15:47:12 EDT
test with rm -rf /tmp/*
Comment 110 Elia Devito 2013-10-31 15:50:52 EDT
test with rm -rf /tmp/* and reboot

when not start: killall ksmserver and  re-login

This isn't a solution but help
Comment 111 carlos.rca185 2013-10-31 16:53:10 EDT
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).
Comment 112 Jeremy Petersen 2013-10-31 17:16:39 EDT
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?
Comment 113 carlos.rca185 2013-10-31 17:52:19 EDT
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
Comment 114 Jeremy Petersen 2013-10-31 18:14:34 EDT
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.
Comment 115 carlos.rca185 2013-10-31 18:22:18 EDT
This 5 files are which must be edited for KDE start works.Sorry.
Comment 116 Elias Vanderstuyft 2013-10-31 18:23:56 EDT
(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).
Comment 117 Jeremy Petersen 2013-10-31 18:28:28 EDT
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.
Comment 118 Jeremy Petersen 2013-11-01 16:00:38 EDT
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.
Comment 119 Al 2013-11-01 16:14:17 EDT
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.
Comment 120 Elias Vanderstuyft 2013-11-01 16:14:46 EDT
(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!
Comment 121 Elias Vanderstuyft 2013-11-01 16:17:57 EDT
(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.
Comment 122 scottvalen 2013-11-03 21:59:46 EST
(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.
Comment 123 Al 2013-11-03 22:21:26 EST
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.
Comment 124 Elias Vanderstuyft 2013-11-04 14:15:50 EST
(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.)
Comment 125 Rex Dieter 2013-11-08 08:33:41 EST
*** Bug 1028425 has been marked as a duplicate of this bug. ***
Comment 126 Denis Kaznadzey 2013-11-14 08:55:05 EST
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)
Comment 127 Riku Seppala 2013-11-16 05:20:11 EST
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)
Comment 128 carlos.rca185 2013-11-16 06:05:19 EST
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
Comment 129 carlos.rca185 2013-11-16 06:29:22 EST
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
Comment 130 carlos.rca185 2013-11-17 11:01:29 EST
modify only kmix_autostart.desktop doesn't work. :(
Comment 131 carlos.rca185 2013-11-19 11:00:16 EST
Today I have experimented this bug with all files modified :/ In the last session I made some configuration changes in KDE.
Comment 132 Elias Vanderstuyft 2013-11-19 13:28:01 EST
(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?
Comment 133 carlos.rca185 2013-11-19 13:37:51 EST
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.
Comment 134 Elias Vanderstuyft 2013-11-19 15:26:20 EST
(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.
Comment 135 carlos.rca185 2013-11-19 19:09:17 EST
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.
Comment 136 Jeremy Petersen 2013-11-20 11:57:09 EST
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
Comment 137 Elias Vanderstuyft 2013-11-20 14:19:28 EST
(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)
Comment 138 Ngo Than 2013-11-28 08:24:27 EST
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
Comment 139 Rex Dieter 2013-11-28 08:28:09 EST
That seems to help for some (all machines @ my site, for example), but not for others, if you read the history of this bug.
Comment 140 David Jones 2013-11-28 09:36:34 EST
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?
Comment 141 Elia Devito 2013-11-28 09:48:37 EST
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
Comment 142 Elias Vanderstuyft 2013-11-28 14:56:15 EST
(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.
Comment 143 Kevin Kofler 2013-11-29 12:30:57 EST
(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.
Comment 144 Kevin Kofler 2013-11-30 08:36:46 EST
*** Bug 1030726 has been marked as a duplicate of this bug. ***
Comment 145 Murzik2142 2013-11-30 10:02:12 EST
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
Comment 146 Murzik2142 2013-11-30 10:36:01 EST
(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
Comment 147 Elias Vanderstuyft 2013-11-30 11:23:23 EST
(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.)
Comment 148 Marcelo Ricardo Leitner 2013-12-02 14:13:59 EST
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!
Comment 149 Kevin Kofler 2013-12-02 16:37:44 EST
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;
        });
Comment 150 Kevin Kofler 2013-12-02 16:40:16 EST
(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)
Comment 151 Marcelo Ricardo Leitner 2013-12-02 16:58:13 EST
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?
Comment 152 Martin Bříza 2013-12-04 11:41:01 EST
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.
Comment 153 Adam Williamson 2013-12-06 02:18:20 EST
*** Bug 1032921 has been marked as a duplicate of this bug. ***
Comment 154 Adam Williamson 2013-12-06 02:21:17 EST
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 .
Comment 155 Elias Vanderstuyft 2013-12-06 03:58:07 EST
Finally this bug is accepted as a blocker.
Comment 156 Adam Williamson 2013-12-06 05:04:23 EST
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.
Comment 157 Kevin Kofler 2013-12-06 10:52:18 EST
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.
Comment 158 john5342 2013-12-06 12:29:06 EST
(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
Comment 159 john5342 2013-12-06 12:40:11 EST
(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.
Comment 160 Fedora Update System 2013-12-07 00:12:15 EST
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
Comment 161 Fedora Update System 2013-12-07 00:43:59 EST
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
Comment 162 Adam Williamson 2013-12-07 03:47:11 EST
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!
Comment 163 Elias Vanderstuyft 2013-12-07 06:17:35 EST
(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?
Comment 164 Elias Vanderstuyft 2013-12-07 06:20:06 EST
Created attachment 833866 [details]
Gdb log of ksmserver when issuing shutdown command

See comment #163 for more details.
Comment 165 Kevin Kofler 2013-12-07 06:22:58 EST
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.
Comment 166 Elias Vanderstuyft 2013-12-07 09:11:27 EST
(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.
Comment 167 Elias Vanderstuyft 2013-12-07 09:13:27 EST
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.
Comment 168 Dr. David Alan Gilbert 2013-12-07 11:35:16 EST
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 169 Kevin Kofler 2013-12-07 13:57:02 EST
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.
Comment 170 Dan Mossor [danofsatx] 2013-12-08 03:04:26 EST
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.
Comment 171 Kevin Kofler 2013-12-08 10:17:49 EST
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.)
Comment 172 Kevin Kofler 2013-12-08 10:20:03 EST
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.)
Comment 173 Adam Williamson 2013-12-08 14:15:09 EST
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.
Comment 174 Adam Williamson 2013-12-08 14:28:10 EST
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!
Comment 175 Adam Williamson 2013-12-08 14:38:10 EST
sigh, i keep saying 2.36 and 2.38 when I mean 2.34 and 2.36.
Comment 176 Allison Karlitskaya 2013-12-08 14:41:47 EST
https://bugzilla.gnome.org/show_bug.cgi?id=711090 is about fixing a deadlock-causing mainloop regression that got introduced at around that time...
Comment 177 Allison Karlitskaya 2013-12-08 14:44:35 EST
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.
Comment 178 Kevin Kofler 2013-12-08 16:50:40 EST
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).
Comment 179 Adam Williamson 2013-12-08 21:00:43 EST
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!
Comment 180 Riku Seppala 2013-12-09 05:28:07 EST
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)
Comment 181 Martin Bříza 2013-12-09 10:51:17 EST
(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.
Comment 182 Adam Williamson 2013-12-09 11:02:18 EST
martin: riku: how often do you usually hit the bug?
Comment 183 carlos.rca185 2013-12-09 11:50:01 EST
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.
Comment 184 Dan Mossor [danofsatx] 2013-12-09 15:07:53 EST
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
Comment 185 Fedora Update System 2013-12-09 16:39:49 EST
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
Comment 186 Fedora Update System 2013-12-10 01:57:58 EST
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.
Comment 187 Martin Bříza 2013-12-11 06:32:40 EST
(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.
Comment 188 Elias Vanderstuyft 2013-12-11 07:24:46 EST
Will there also be an update for Fedora 19?
Comment 189 Rex Dieter 2013-12-11 07:46:55 EST
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.
Comment 190 Fedora Update System 2013-12-11 21:52:51 EST
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.
Comment 191 Al 2013-12-12 10:04:57 EST
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.  ;-{
Comment 192 Rex Dieter 2013-12-12 10:11:55 EST
delay is sometimes not too abnormal, but this bug was about autostart items not starting *at all*.
Comment 193 Elias Vanderstuyft 2013-12-12 12:49:03 EST
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.
Comment 194 Elias Vanderstuyft 2013-12-12 12:57:42 EST
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.

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