Either some sddm'ism or a dup of bug #983110

retesting this as KDE x86_64 TC2 netinstall to VirtualBox

(In reply to satellit from comment #2)
> retesting this as KDE x86_64 TC2 netinstall to VirtualBox

shutdown works here.... about a 2 minute wait to close but had popup to shutdown here.

I will redownload the DVD and retest.

I jus did a install from the same DVD.iso to VirtualBox and shutdown works so somehow my baremetsl DVD install to HD did not work correctly.

>This may be a false bug.<

Still downloading the DVD a 2nd time (eta 39 minutes) and will repeat the bare
metal install.

(In reply to satellit from comment #4)
> I jus did a install from the same DVD.iso to VirtualBox and shutdown works
> so somehow my baremetsl DVD install to HD did not work correctly.
> 
> >This may be a false bug.<
> 
> Still downloading the DVD a 2nd time (eta 39 minutes) and will repeat the
> bare
> metal install.

On install with 2nd DVD to HD shutdown works.
NOT A BUG

dd USB DVD install to HD does not shutdown so reopened

I just did a install from the same DVD.iso to VirtualBox and shutdown works so somehow my baremetsl DVD install to HD did not work correctly.

>This may be a false bug.<

Still downloading the DVD a 2nd time (eta 39 minutes) and will repeat the bare
metal install.

See again in dd DVD USB install to HD

Hope I set this as Proposed freeze Exception

I've confirmed this on i686 installation to bare metal.

when you say 'confirmed this' - is the bug that it sometimes works, sometimes fails? always fails? seems a bit confused.

it does not happen on all installs for me but maybe 40% of the time. could dbus be blocked ? Or systemd? (only guesses) no idea why; just see it happen

"Confirmed this" simply means that I ran an installation of KDE to bare metal and the panel didn't work for shutting down - no pop up. 

Attempted it with x86_64 DVD on bare metal and within a VM - didn't hit this error. So I guess now, "confirmed this" means that this is a bug that sometimes works and sometimes fails.

I see it on x86_64 bare metal install. FWIW, I see it on F19 occasionally too. It seems to be related to something failing to start during KDE startup.

I also see that when it's failing, actions like alt-F2 for krunner fail,, kmix fails to showup in the taskbar, and very occasionaly, launching an app from the menu, or desktop context menu fails for the first minute or so of a session. Manually starting these apps works.

Various fixes around the net appear to work, but usually only for one or 2 logins (rm /var/tmk/kde-cache, changing startup phase in /usr/share/autostart). On F19, these fixes are usually permanent (it rarely re-occurs once initially fixed)

Any advice on determining what autostart has started, and what failed would help narrow it down I think. 

My software package selection was KDE desktop, and various developer tools (no customisations beyond the basic selections)

Bare metal install from DVD x86_64 to external USB 500GB HD. no shutdown pop up to confirm shutdown. nothing happens   use poweroff from terminal to shutdown

It'll be interesting to see if the switch to KDM by default fixes this...could anyone affected try replacing SDDM with KDM and see if it helps?

Discussed at 2013-11-27 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . This was accepted as a freeze exception issue, but then actually promoted to blocker status, as it seems like a fairly clear violation of Beta criterion https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Desktop_shutdown.2C_reboot.2C_logout : "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work." - pretty hard to argue KDE is meeting that criterion as described. We're willing to revisit this decision if further data indicates the failure is quite rare.

As noted in c#16, it's possible the switch to KDM-by-default may fix this. That change is not in TC3, but will be in TC4.

This feels very much like bug 983110 in that:
    - it fails to shutdown
    - it only happens to some people sometimes

On that the way to tell is that you should have a polkit-kde-authentication-agent-1 running - i.e. you should see:

[dg@major ~]$ ps -eaf|grep -i polkit-kde-aut
dg        1878     1  0 10:42 ?        00:00:00 /usr/libexec/kde4/polkit-kde-authentication-agent-1
dg       17763 17730  0 21:48 pts/8    00:00:00 grep --color=auto -i polkit-kde-aut

if that's missing when it fails and present when it works I say it's the same bug.

Comments 21/24 of that bug suggest ways to restart the agent, so again if that trick works to restart I suggest it's the same bug.
(Suggestion without actually knowing how it's all wired).

Kevin Kofler agreed with the idea t hat this is a dupe of 983110, fwiw. Can people affected please check and confirm?

This will be fixed by switching to KDM.

set to modified as the bug will be fixed by switching to kdm

I do use kdm and the isn't fixed yet

(In reply to Elia Devito from comment #22)
> I do use kdm and the isn't fixed yet

*the bug

Elia, you're likely seeing a bug #983110 then, can you verify the symptom per comment #18 ?

I confirm that symptom and I suppose it's a duplicate of #983110

Resetting MODIFIED → NEW, it's not related to SDDM.

why not just dupe it, then?

I am on F20 TC3.  My path was to install the KDE spin of F19 last week, then do a fedup on Sunday 1 December to F20 TC3.  I read the previous comments. I don't have GDM or SDDM installed at all, only KDM.  I also don't have  Virt-Manager as referenced in bug 983110.  I have seen twice since Sunday where I can't logout or reboot.  To clear the condition I have had to open a terminal and reboot via command line. It may or may not be related but when this happened the volume control buttons on my laptop quit working. I could mute sound, but could not change volume.  I don't think the bug is fixed by switching to KDM.  

The next time it happens I will verify symptoms as per comment 18 of this bug.

> why not just dupe it, then?

Because this one is marked AcceptedBlocker and the other one is not? ;-)

The blocker status can be transferred.

The other difference is that bug #983110 is against F19. For KDE stuff, that doesn't make much of a difference because we try to keep things in sync and apply fixes everywhere, but if the fix ends up being in systemd, it does (because they backport only selected fixes).

Anyone (still) seeing this, can you please try this update for bug #1006386:
https://admin.fedoraproject.org/updates/systemd-208-8.fc20
and see whether that also fixes this bug? (We have always suspected that bug #1006386 was the root cause of bug #983110.)

Worth noting the fix for 1006386 in 208-8 is not a sure thing, so it'd be best to keep an eye on that bug report and see whether people's experience is that that bug is really fixed or not.

since this issue does appear only random and i cannot reproduce this issue on several machines.  Anyone seeing this issue, please try to update systemd-208-8.fc20 and test again.

thanks

If you wonder how to install the systemd update, try:
yum --enablerepo=updates-testing --advisory=FEDORA-2013-22704 update

I just ran into this one for the first time yesterday. I am running a less than week old bare-metal install of TC3 with updates up to yesterday applied. I ran through the gamut of what I could think of, and have come up with a few more details although I'm not sure how pertinent they are.

The icons that work: Lock, Sleep, Hibernate, and Switch Users.
The icons that don't work: Logout, Restart, and Shutdown. Kmix is also not running.

I used the suggestion from comment 18 and checked to see if the polkit-kde-authentication-agent was running, and it was not. I restarted it with this output:

[root@g55 ~]/usr/libexec/kde4/polkit-kde-authentication-agent-1
New PolkitAgentListener  0xffd200 
Adding new listener  PolkitQt1::Agent::Listener(0x1158300) for  0xffd200 

I installed the systemd-208 update from comment 32, and still have the same results. 

Switching users worked before the systemd-208 update, and the other (non-admin) user could log out. After the update, the second desktop can't be initialized (which may be unrelated, still need to verify).

dan: can you read https://bugzilla.redhat.com/show_bug.cgi?id=1006386 and see if it looks like you're affected by that bug from your logs, with the new systemd? Thanks!

So I've hit this bug with systemd-208-8.fc20 without trying very hard at all. I just installed TC5 x64 KDE desktop live (which has that systemd), booted the installed system, did an update (only pulled NetworkManager, I think we left it out of TC5 by mistake or something...), installed all the debuginfo for kde-workspace, and clicked around the panel a bit. Then I shut down, went out for dinner, came back, and powered the VM up...and hit the bug. Sitting at a desktop now with no kmix in the panel and the "Shut Down" option in the kicker does nothing.

As regards 1006386, the "Time spent on flushing to /var" on the affected boot was a whole 102.404ms - as I understand that bug, it seems to be associated with a long "Time spent on flushing", so this would be a further indication that bug really isn't the cause of this one.

I'll attach the journal from my affected system; it's very clean and contains precisely one 'successful' boot and one 'failed' boot, so it may be useful for comparison purposes. The 'successful' boot is the first, around 15:40; the 'failed' boot is the second, around 22:55.

Created attachment 833442 [details]
journal from a fairly clean affected VM (installed from F20 Final TC5 x64 KDE live, contains one boot that does not hit the bug at 15:40, one boot that hit the bug at 22:55)

let's just dupe the damn thing already, this is clearly the same as 983110.

*** This bug has been marked as a duplicate of bug 983110 ***