[karmic] Unable to logout/reboot/shutdown from within KDE

Version: (using KDE 4.2.98)
OS: Linux
Installed from: Ubuntu Packages

I am running KDE 4.3 RC3 in Kubuntu Jaunty, from the corresponding PPA build:
http://www.kubuntu.org/news/kde-4.2.98

This is an upgrade from 4.2.4 (from the Jaunty PPA, too). Everything works fine, except for logout, which just doesn't work. Actually, none of the logout options works (logout, reboot, etc). After choosing the selected option, and confirming that you want to logout, nothing happens.

Other users have verified this behavior, so it is possible but unlikely that this is something local to my machine:
http://kubuntuforums.net/forums/index.php?topic=3105306.0

I rushed to make this bug report due to the proximity of the KDE 4.3 release. Please let me know if there is anything else I can try to debug this.

Thank you for one more splendid release (everything else is outstanding)!
-- Leo

Are you using desktop effects? If yes please try without (alt+shift+f12) and report if it changes anything? If it doesn't change anything we have to reassign.

I also am running Kubuntu Jaunty with KDE 4.3 RC3 but my logout and reboot work fine. One difference I see is I have had the betas and RC 1 and 2 installed prior to this. I did not jump from 4.2.4 to 4.2.98.

@Martin: desktop effects are disabled, thanks for the suggestion.

@zerix: are you using KDM, KDM-4? I am using GDM because it makes a certain workaround for poor performance in Intel IGP's easier. I will try with KDM now.

(In reply to comment #3)
> @Martin: desktop effects are disabled, thanks for the suggestion.
In that case: reassign to ksmserver as kwin doesn't handle anything with logout for non-composited environments

Thanks Martin for the reassignment.

Lubos et al: I tried removing gdm and installing kdm, and same thing. I will keep poking around.

I just tested more.

* Only two logout options work: Suspend to RAM and Start a New Session.
* KDM or GDM doesn't matter.
* I added a new user (to test with vanilla configuratios). The new user CAN logout. However, it is greeted by a black screen (the xserver dies at logout, but I am sure this is something else).

Update: in GDM, the new account can logout fine and go back to the GDM window just fine. There is some problem with KDE 4.3 running as an upgrade (as opposed to a fresh install).

I am running KDM 4.2.98. I do not have GDM installed. I didn't mention this before but I am using compositing.

Same here. Can't log out, can't shut down, can't restart, can't switch user.

First attempt to shut down brings up a shut down dialogue (which one depends on the menu item (Leave -> whatever) or panel/desktop widget used). Doesn't do anything, though. And no further dialogue boxes appear on subsequent attempts.

Switch user brings up a narrow horizontal "plasma box" with just an "X" button on it (which closes it); no text or anything.

Sleep and Lock Screen work.

Upgraded from Kubuntu 8.04 to 8.10 to 9.04, KDE likewise stepwise to the 4.3 release candidates, now at 4.2.98 (4.3 RC3). Was using KDM, then GDM, makes no difference. Desktop effects on or off makes no difference.

I can confirm this bug with Kubuntu 9.04, KDE 4.3 Final, and I believe it is related to KNotify hanging (or crashing) when attempting to play the logout sound. Hence the bug may need to be reassigned to KNotify.

On my system I can fix the problem by disabling the logout sound in System Settings->Notifications->KDE System Notifications, and then unchecking play sound for Logout. Can anyone else confirm this workaround? Alternatively you can try removing your ~/.kde/share/config/knotifyrc)

To Reproduce: From a brief investigation: Using the following knotifyrc on a clean user account with KDE4.3 will cause the bug:

knotifyrc:

[Misc]
LastConfiguredApp=KDE System Notifications

[Phonon::AudioOutput]
KNotify_Volume=1

[Sounds]
No sound=true
Use external player=false
Volume=100

(Note: This will also have other symptoms, such as slower login due to startup sounds failing, but it isn't noticed so strongly.)

Theory: (this is unconfirmed, I have only briefly browsed the code and don't have a dev environment handy to check this): If sounds are still set for events, but sound is disabled in knotifyrc, then knotify's NotifyBySound::notify() does not check it's NoSound variable and will try to load and play the sound, I think on a non-existant player (and hence hang or crash).

Possible fix:
Add the following to the very beginning of NotifyBySound::notify() in notifybysound.cpp:

if(d->playerMode == Private::NoSound)
{
    finish( eventId );
    return;
}

It would be nice if someone could confirm any of this.

I think I can confirm this. It seems I can work around the problem by explicitly unchecking "play sound" for the logout event in _addition_ to my usual preference (notification sounds turned off altogether). Or I can leave everything in its default state, as for a new user/with an untouched knotifyrc, and let all sounds play but turn down the volume on the notifications.

Additionally, login or logout leave me with a maximally core-hogging kded4 process unless they have "Play a sound" unchecked. This happens even with notification sounds turned off globally ("No sound=true" in knotifyrc).

Sorry, correction: Login and other events I've tried (empty trash, change desktop, close window) are "allowed" to have a sound associated with them as long as "No sound=true". (Testing the sound in the System Settings module, however, will still jump kded4 to 99% CPU (or core))

Great find, Daniel!

I can confirm what was suspected by Daniel Brownlees (and also confirmed by Astera). I went to System Settins -> Notification and chose the default settings, and sure enough, I was able to logout right away.

As an alternative to checking for a null player (or NoSound), wouldn't it be possible to make these notification asynchronous, such that no other process waits for them and login/logout can complete even if they fail, or take longer than normal?)

Great find, Daniel!

I can confirm what was suspected by Daniel Brownlees (and also confirmed by Astera). I went to System Settings -> Notification and chose the default settings, and sure enough, I was able to logout right away.

As an alternative to checking for a null player (or NoSound), wouldn't it be possible to make these notification asynchronous, such that no other process waits for them and login/logout can complete even if they fail, or take longer than normal?)

Leo Milano wrote:
> As an alternative to checking for a null player (or NoSound), wouldn't it be
> possible to make these notification asynchronous, such that no other process
> waits for them and login/logout can complete even if they fail, or take longer
> than normal?)

I think that is a separate issue, though a good suggestion to make the logout procedure more robust.

There is still the bug in KNotify where it will load and then attempt to play a sound file even when it never initialised a player because NoSound is set. The bug actually gets tripped by all sorts of things - login sounds, alerts, or any other sound event, but because it doesn't block anything else, and the expected behaviour is correct (as in, no sound is produced) I don't think it has ever been noticed.

*** This bug has been confirmed by popular vote. ***

Hi Daniel

I agree, this has to be fixed anyway.

> There is still the bug in KNotify where it will load and then attempt to play a
> sound file even when it never initialised a player because NoSound is set.

Are you sure about this? I am looking at the function (maybe it was recently fixed). It doesn't seem to be attempting to _play_ it if the Private object is set to NoSound. It is actually doing this [1]:

00235 if(d->playerMode == Private::UsePhonon)
00236 {
00237 Player *player = d->playerPool.getPlayer();
00238 connect(player->media, SIGNAL(finished()), d->signalmapper, SLOT(map()));
00239 d->signalmapper->setMapping(player->media, eventId);
00240 player->play(soundFile);
00241 d->playerObjects.insert(eventId, player);
00242 }
00243 else if (d->playerMode == Private::ExternalPlayer && !d->externalPlayer.isEmpty())
00244 {
00245 // use an external player to play the sound
00246 KProcess *proc = new KProcess( this );
00247 connect( proc, SIGNAL(finished(int, QProcess::ExitStatus)),
00248 d->signalmapper, SLOT(map()) );
00249 d->signalmapper->setMapping( proc , eventId );
00250
00251 (*proc) << d->externalPlayer << soundFile;
00252 proc->start();
00253 }

So, in our case, both if() conditions will be false, and we'll just exit the function. However, we are not calling finish( eventId ) , which seems mandatory for other processes calling us to know _we_ are done [2]. So, the clean way to do this is to include it in the same if, just add one more condition (basically, the code you suggested above, but in line 254, in an else if() condition.

Cheers,
-- Leo

[1] http://api.kde.org/4.x-api/kdebase-runtime-apidocs/knotify/html/notifybysound_8cpp_source.html
[2] http://api.kde.org/4.x-api/kdebase-runtime-apidocs/knotify/html/classKNotifyPlugin.html#aac39c9af1599b8b4c60406eb8145d08c

Hi Leo
>
> Are you sure about this? I am looking at the function (maybe it was recently
> fixed). It doesn't seem to be attempting to _play_ it if the Private object is
> set to NoSound.

No, I am definately not sure :). I agree with your reading.

> However, we are not calling finish( eventId ) , which seems mandatory
> for other processes calling us to know _we_ are done [2]. So, the clean way to
> do this is to include it in the same if, just add one more condition
> (basically, the code you suggested above, but in line 254, in an else if()
> condition.

Still, why load the sound file if it won't be played? I would think
the cleanest solution is to check at the beginning of the function and
close the event appropriately.

BTW. Has anyone been able to test this and see if it resolves the logout bug?

No, I haven't been able to confirm the fix. I am running pre-compiled binaries (Kubuntu's).

I think it's a judgement call, more clear/robust (IMO) code vs a bit more performance. I always prefer the former, but I think both ways it's ok. What seems evident, in any case, it that there is an execution path here not sending the right message to the caller (that is, not calling finish( eventId ), so the caller will wait forever.

Mmm. This needs to be fixed, does knotify have a maintainer? Are people on vacation? I could fix this, but I need to set up a dev environment, get a subversion account, reproduce, test, and commit, all in my very little spare time, which probably means it will take a long time. For a maintainer it's probably a 10 minute ordeal all together :)

But please let me know if this has been orphaned, and I'll do what I can ...

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

Created attachment 36296
Close event when NoSound is set

Here is a patch that fixes this issue, as I discussed above. It closes the event if NoSound is set, rather than leaving it open. I have tested on the 4.3 branch and it fixes this issue.

Can someone please apply this for 4.3.1? It should be applied to trunk as well.

Further background: The issue is exposed by R997746 (trunk) which has been backported to the Kubuntu packages. The revision removes the 6 second timeout on events preventing them closing automatically, so hence the sound event stays open indefinitely. Any other sound events will also never close The above fix also has the upside that it speeds login and logout up by those six seconds if NoSound is set in vanilla 4.3 without R997746 :-).

SVN commit 1013912 by ogoffart:

Do not try to load the sound file if we are not going to play a sound.
And close the Notification right away

Thanks to Daniel Brownlees

BUG: 201569

 M +7 -1 notifybysound.cpp

WebSVN link: http://websvn.kde.org/?view=rev&revision=1013912

I have the same bug now with the KDE4.4 (4.3.95) in Kubuntu x64 and even with deleting ~/.kde directory, deleting KDE-related packages and installing KDE4.3.5.

I can confirm that this bug reappeared in KDE 4.4.2 in Kubuntu. Disabling sounds (one by one) in KNotify settings workaround worked for me

still persist in 4.7.3

only fixed when disable close sesson sound in knotify settings