Bug 1032921 - KDE f20 TC2 x86_64 fails to shutdown from menu bar
KDE f20 TC2 x86_64 fails to shutdown from menu bar
Status: CLOSED DUPLICATE of bug 983110
Product: Fedora
Classification: Fedora
Component: kde-workspace (Show other bugs)
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F20FinalBlocker
  Show dependency treegraph
Reported: 2013-11-21 04:12 EST by satellitgo
Modified: 2013-12-06 02:18 EST (History)
20 users (show)

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

Attachments (Terms of Use)
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) (277.49 KB, text/plain)
2013-12-06 02:12 EST, Adam Williamson
no flags Details

  None (edit)
Description satellitgo 2013-11-21 04:12:51 EST
Description of problem: KDE f20 TC2 x86_64 fails to shutdown from menu bar

Version-Release number of selected component (if applicable):
DVD install of KDE f20 TC2 x86_64
KDE Plasma Workspace  US 

How reproducible:

Steps to Reproduce:

Actual results:
shutdown; restart; logout do nothing. 
Pop UP confirmation window never appears

Expected results:
shutdown; restart; logout; to work

Additional info:
Requires shutdown -h now from terminal
Comment 1 Rex Dieter 2013-11-21 06:27:58 EST
Either some sddm'ism or a dup of bug #983110
Comment 2 satellitgo 2013-11-21 07:56:40 EST
retesting this as KDE x86_64 TC2 netinstall to VirtualBox
Comment 3 satellitgo 2013-11-21 08:34:23 EST
(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.
Comment 4 satellitgo 2013-11-21 08:58:16 EST
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.
Comment 5 satellitgo 2013-11-21 11:45:50 EST
(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.
Comment 6 satellitgo 2013-11-21 18:31:13 EST
dd USB DVD install to HD does not shutdown so reopened
Comment 7 satellitgo 2013-11-21 19:08:31 EST
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.
Comment 8 satellitgo 2013-11-21 19:10:04 EST
See again in dd DVD USB install to HD
Comment 9 satellitgo 2013-11-21 21:17:57 EST
Hope I set this as Proposed freeze Exception
Comment 10 Mike Ruckman 2013-11-21 21:32:47 EST
I've confirmed this on i686 installation to bare metal.
Comment 11 Adam Williamson 2013-11-21 21:57:07 EST
when you say 'confirmed this' - is the bug that it sometimes works, sometimes fails? always fails? seems a bit confused.
Comment 12 satellitgo 2013-11-21 22:09:15 EST
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
Comment 13 Mike Ruckman 2013-11-22 13:15:05 EST
"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.
Comment 14 Darren Steven 2013-11-26 06:12:27 EST
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)
Comment 15 satellitgo 2013-11-27 12:01:14 EST
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
Comment 16 Adam Williamson 2013-11-27 14:16:10 EST
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?
Comment 17 Adam Williamson 2013-11-27 14:23:26 EST
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.
Comment 18 Dr. David Alan Gilbert 2013-11-27 16:50:11 EST
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).
Comment 19 Adam Williamson 2013-11-27 17:18:32 EST
Kevin Kofler agreed with the idea t hat this is a dupe of 983110, fwiw. Can people affected please check and confirm?
Comment 20 Martin Bříza 2013-11-28 09:51:34 EST
This will be fixed by switching to KDM.
Comment 21 Ngo Than 2013-11-29 11:18:10 EST
set to modified as the bug will be fixed by switching to kdm
Comment 22 Elia Devito 2013-12-02 12:09:26 EST
I do use kdm and the isn't fixed yet
Comment 23 Elia Devito 2013-12-02 12:11:48 EST
(In reply to Elia Devito from comment #22)
> I do use kdm and the isn't fixed yet

*the bug
Comment 24 Rex Dieter 2013-12-02 12:25:10 EST
Elia, you're likely seeing a bug #983110 then, can you verify the symptom per comment #18 ?
Comment 25 Elia Devito 2013-12-02 12:37:18 EST
I confirm that symptom and I suppose it's a duplicate of #983110
Comment 26 Kevin Kofler 2013-12-03 12:18:13 EST
Resetting MODIFIED → NEW, it's not related to SDDM.
Comment 27 Adam Williamson 2013-12-03 12:56:04 EST
why not just dupe it, then?
Comment 28 David Green 2013-12-03 14:50:45 EST
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.
Comment 29 Kevin Kofler 2013-12-03 18:53:02 EST
> why not just dupe it, then?

Because this one is marked AcceptedBlocker and the other one is not? ;-)
Comment 30 Adam Williamson 2013-12-03 18:59:20 EST
The blocker status can be transferred.
Comment 31 Kevin Kofler 2013-12-03 19:06:11 EST
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).
Comment 32 Kevin Kofler 2013-12-04 07:41:27 EST
Anyone (still) seeing this, can you please try this update for bug #1006386:
and see whether that also fixes this bug? (We have always suspected that bug #1006386 was the root cause of bug #983110.)
Comment 33 Adam Williamson 2013-12-04 12:29:09 EST
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.
Comment 34 Ngo Than 2013-12-05 05:33:13 EST
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.

Comment 35 Kevin Kofler 2013-12-05 10:04:12 EST
If you wonder how to install the systemd update, try:
yum --enablerepo=updates-testing --advisory=FEDORA-2013-22704 update
Comment 36 Dan Mossor [danofsatx] 2013-12-05 10:35:16 EST
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).
Comment 37 Adam Williamson 2013-12-05 12:49:58 EST
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!
Comment 38 Adam Williamson 2013-12-06 02:11:52 EST
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.
Comment 39 Adam Williamson 2013-12-06 02:12:56 EST
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)
Comment 40 Adam Williamson 2013-12-06 02:18:20 EST
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 ***

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