Bug 201569 - Unable to logout in KDE 4.3 RC3
Summary: Unable to logout in KDE 4.3 RC3
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: knotify (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal with 90 votes (vote)
Target Milestone: ---
Assignee: Olivier Goffart
URL:
Keywords:
: 203358 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-26 17:46 UTC by Leo Milano
Modified: 2013-06-05 21:31 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Close event when NoSound is set (515 bytes, patch)
2009-08-20 13:37 UTC, Daniel Brownlees
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leo Milano 2009-07-26 17:46:29 UTC
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
Comment 1 Martin Flöser 2009-07-26 18:05:13 UTC
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.
Comment 2 Zerix01 2009-07-26 21:22:14 UTC
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.
Comment 3 Leo Milano 2009-07-26 22:14:51 UTC
@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.
Comment 4 Martin Flöser 2009-07-26 22:26:32 UTC
(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
Comment 5 Leo Milano 2009-07-26 22:35:41 UTC
Thanks Martin for the reassignment.

Lubos et al: I tried removing gdm and installing kdm, and same thing. I will keep poking around.
Comment 6 Leo Milano 2009-07-26 23:31:30 UTC
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).
Comment 7 Leo Milano 2009-07-27 04:58:32 UTC
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).
Comment 8 Zerix01 2009-07-27 06:15:25 UTC
I am running KDM 4.2.98. I do not have GDM installed. I didn't mention this before but I am using compositing.
Comment 9 anj.tuesday 2009-08-02 15:17:24 UTC
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.
Comment 10 Daniel Brownlees 2009-08-05 12:01:50 UTC
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.
Comment 11 anj.tuesday 2009-08-05 16:02:05 UTC
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.
Comment 12 anj.tuesday 2009-08-05 16:27:07 UTC
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).
Comment 13 anj.tuesday 2009-08-05 17:07:20 UTC
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))
Comment 14 Leo Milano 2009-08-06 02:11:07 UTC
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?)
Comment 15 Leo Milano 2009-08-06 02:14:25 UTC
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?)
Comment 16 Daniel Brownlees 2009-08-06 02:45:11 UTC
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.
Comment 17 Michael Sprauer 2009-08-09 23:13:14 UTC
*** This bug has been confirmed by popular vote. ***
Comment 18 Leo Milano 2009-08-10 04:45:36 UTC
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
Comment 19 Daniel Brownlees 2009-08-10 05:44:42 UTC
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?
Comment 20 Leo Milano 2009-08-10 15:26:11 UTC
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.
Comment 21 Leo Milano 2009-08-11 15:05:15 UTC
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 ...
Comment 22 Lubos Lunak 2009-08-12 13:30:04 UTC
*** Bug 203358 has been marked as a duplicate of this bug. ***
Comment 23 Daniel Brownlees 2009-08-20 13:37:35 UTC
Created attachment 36296 [details]
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 :-).
Comment 24 Olivier Goffart 2009-08-21 09:46:26 UTC
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
Comment 25 Tom Kijas 2010-02-03 10:50:15 UTC
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.
Comment 26 Frantisek Sindelar 2010-04-08 13:28:04 UTC
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
Comment 27 Gustavo Alvarez 2011-11-27 20:24:36 UTC
still persist in 4.7.3

only fixed when disable close sesson sound in knotify settings