Bug 328571 - autostart never finishes, ksmserver ignores logout/shutdown
Summary: autostart never finishes, ksmserver ignores logout/shutdown
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdeinit (show other bugs)
Version: 4.11.3
Platform: Fedora RPMs Linux
: NOR grave
Target Milestone: ---
Assignee: kdelibs bugs
URL: https://bugzilla.redhat.com/show_bug....
Keywords:
: 252068 327543 339122 347206 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-09 12:48 UTC by Rex Dieter
Modified: 2016-01-20 23:09 UTC (History)
28 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.15


Attachments
Program that hangs the autostart sequence (794 bytes, text/plain)
2014-07-19 15:07 UTC, Felipe Sateler
Details
Plasma 5 boot log (89.39 KB, text/plain)
2015-07-02 12:55 UTC, Tomasz Figa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rex Dieter 2013-12-09 12:48:07 UTC
Some downstream fedora users are experiencing the bad effects of kde autostart phases (usually phase 2) that never finish

Reproducible: Sometimes

Steps to Reproduce:
Reproducibility is difficult.  Fedora developers have generally been unable to do so, though as evidenced by the downstream report, 
https://bugzilla.redhat.com/show_bug.cgi?id=983110
quite a few users hit this
Actual Results:  
This problem has several bad effects:
* not all autostart items get processed
* ksmserver does not process logout/shutdown events (since it thinks autostart is still underway).

Expected Results:  
autostart/logout/shutdown work as expected

A lot of things have been tried so far, but one that is promising for at least one user, that setting
QT_NO_GLIB=1; export QT_NO_GLIB;
seems to help ( see https://bugzilla.redhat.com/show_bug.cgi?id=983110#c170 )
Comment 1 Kevin Kofler 2013-12-09 13:09:59 UTC
Actually, in the logs I've seen, we get stuck during phase 1 (on the machine I got the logs from, whenever it happened at all (which was not 100% of the time), it consistently happened after starting nepomukserver), phase 2 doesn't even start.
Comment 2 Harald Held 2013-12-10 06:37:25 UTC
This is not only related to Fedora. I'm using Arch and this happens to me a lot, definitely with increasing frequency. I have also seen this on Kubuntu.
Comment 3 Kevin Kofler 2013-12-10 14:34:33 UTC
This workaround appears to work for us:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.11.3-klauncher-no-glib.patch
Comment 4 BT 2014-02-12 09:40:59 UTC
I can confirm the patch from comment 3 fixed the issue for me. I applied the patch against kdelibs 4.11.5 on Gentoo.
Comment 5 Pavel 2014-04-26 16:39:57 UTC
I currently experience this on 4.13, Gentoo.
Comment 6 Kevin Kofler 2014-05-29 23:26:08 UTC
The workaround from comment #3 is still the only fix I'm aware of.
Comment 7 Rex Dieter 2014-07-12 20:37:47 UTC
*** Bug 327543 has been marked as a duplicate of this bug. ***
Comment 8 Felipe Sateler 2014-07-15 14:48:25 UTC
I can confirm that the workaround (QT_NO_GLIB) works for me. I did add it to /etc/environment though. This is on a Debian system.

If there is anything I can do to help find the cause, please let me know.
Comment 9 Felipe Sateler 2014-07-19 15:03:23 UTC
I have to take that back. It seems that the problem for me is autostarting a certain type of application.

I have configured for autostart 3 applications: pasystray, arbtt and a custom python script. As long as I don't activate my custom python script, all seems to be well.

My custom script is very short. All it does is define a function, and hook it up to the org.freedesktop.ScreenSaver.ActiveChanged signal.

Given the information on this bug, I tried both glib and QT mainloops. Both hanged the autostart sequence, and prevented the exit dialogs from appearing.

Disabling the offending application seems to unbreak kde, even without QT_NO_GLIB.
Comment 10 Felipe Sateler 2014-07-19 15:07:36 UTC
Created attachment 87817 [details]
Program that hangs the autostart sequence
Comment 11 Kevin Kofler 2014-07-19 20:25:09 UTC
Then what you are seeing is not this bug, but a different issue with the same symptoms.
Comment 12 Felipe Sateler 2014-07-20 19:51:35 UTC
So, should I file a new bug? I filed #327543 but it was marked as duplicate of this one.
Comment 13 Rex Dieter 2014-07-21 12:53:26 UTC
Your original bug didn't mention the cause being a particular autostart item... I'd suggest filing a new one with that extra bit of detail.
Comment 14 Rex Dieter 2014-07-21 12:54:05 UTC
marking confirmed, fwiw, given at least several independant reporters seeing it too
Comment 15 Felipe Sateler 2014-07-21 14:19:11 UTC
OK, filed new bug #337667
Comment 16 Amichai Rothman 2014-09-10 08:05:31 UTC
Same symptom on Kubuntu 14.04 with KDE 4.14.0. I don't know if it's the same cause, but there is no way to get logout/shutdown/restart dialog to show, either from K menu or tray icon after software updates that says a restart is needed (if I click on the icon, it just disappears with no restart dialog shown.

Does anyone know of another clean way to gracefully shutdown/restart the system without losing app data or session state?
Comment 17 AnAkkk 2014-09-17 17:57:59 UTC
This might actually be the same issue as I've reported here:
https://bugs.kde.org/show_bug.cgi?id=339122
Comment 18 AnAkkk 2014-09-19 21:06:48 UTC
*** Bug 339122 has been marked as a duplicate of this bug. ***
Comment 19 AnAkkk 2014-09-19 21:11:20 UTC
Info from my other bug report:

The issue is that KLauncher::slotNameOwnerChanged isn't called at all (in klauncher.cpp), so mAutotimer in requestDone is never reset, which is why it hangs autostart (and plasmashell is never ran for me). Since it works after restarting the DM, maybe it's because some dbus process is launched too late on the 1st run?

The workaround from #3 fixes the issue for me.
Comment 20 AnAkkk 2014-09-23 13:58:33 UTC
As this bug affects KF5/Plasma 5 too, adding dfaure to the CC list since he's the maintainer.
Comment 21 David Faure 2014-10-12 13:59:12 UTC
I can't debug the issue since it doesn't happen here.
And I can't approve a patch that works around an issue without a proper explanation of what the issue is. "Never commit code you don't understand" is a rather universal rule of software development.

This needs to be debugged by someone who knows about the glib event loop. Maybe Ryan Lortie, the glib maintainer? Or Thiago (QtCore+QtDBus maintainer). Or someone at RedHat, I suppose they know about glib too.
Comment 22 David Faure 2014-10-12 14:04:59 UTC
Ryan, feel like debugging a problem that happens with the glib event loop in Qt, and doesn't when disabling the glib event loop? :-)

KLauncher::slotNameOwnerChanged is connected to the QDBusConnectionInterface::serviceOwnerChanged signal, which is emitted when a dbus service acquires a name. Seems it's not emitted when using the glib event loop in Qt and booting into a KDE workspace on a fast computer, according to AnAkkk.
Comment 23 AnAkkk 2014-11-15 12:06:35 UTC
Anything new ? 

My two computers hit that bug quite often, and I have to open a virtual terminal to shut them down every time, it's quite annoying.

As none seem interested into debugging it, would be nice if the workaround could be merged...
Comment 24 AnAkkk 2014-11-15 12:14:19 UTC
BTW, I wanted ArchLinux to apply the patch but they want you to apply it first:
https://bugs.archlinux.org/task/42385

So I'm sort of stuck with this bug or recompiling the package every time there's a new kinit update, which I'd rather avoid :/
Comment 25 gustavo 2014-11-25 02:33:33 UTC
I confirm this bug on kde 4.13.3 (Ubuntu 14.04).

The symptoms are logout buttons that don't work (both on the plasma bar and on the menu) and kmix not running.

With (QT_NO_GLIB) on /etc/environment ligthdm no longer works (users can write the password but pressing ENTER or clicking on the arrow key won't do anything).
Comment 26 S. Christian Collins 2014-12-12 23:38:18 UTC
i don't know if you're looking for "me too" posts, but I can confirm that the workaround in comment #3 fixes the issue for me as well. I was getting this bug probably one out of every 5-10 times I started up my laptop... after applying the no-glib patch, it starts up perfectly every time!

** My System **
OS: Kubuntu 14.04 amd64 w/ KDE SC 4.13.3
PC: HP Pavilion m6-1035dx
CPU/GPU: AMD A10-4600M APU with Radeon HD 7660G Graphics
RAM: 6GB DDR3 800 MHz
Linux Kernel: 3.13.0-43-generic
Comment 27 S. Christian Collins 2014-12-12 23:41:21 UTC
Also, there seems to have been a lot of sleuthing done on this bug here: https://bugzilla.redhat.com/show_bug.cgi?id=983110
Comment 28 S. Christian Collins 2014-12-12 23:45:23 UTC
The consensus, based on the link that I posted in the previous comment, seems to be that there is a race condition exposed by klauncher's use of the glib mainloop.
Comment 29 apache 2014-12-13 08:57:30 UTC
I'm also affected. KDE 4.13.2 Kubuntu 14.04
Temporary solution: 
delete  .kde/share/config/ksmserverrc
Ctrl+Alt+F1
sudo shutdown -h now
After you log in next time logout, shutdown buttons will react normally.
Comment 30 gustavo 2014-12-13 15:57:13 UTC
Next steps towards getting a fix into the distros?
Comment 31 AnAkkk 2014-12-13 16:27:38 UTC
Some distros like ArchLinux don't want to fix it because there's no official upstream fix.
Comment 32 AnAkkk 2015-03-17 17:14:48 UTC
Apparently QDBusConnectionInterface::serviceOwnerChanged is now obsolete/deprecated, according to http://doc.qt.io/qt-5/qdbusconnectioninterface-obsolete.html

QDBusServiceWatcher must be used instead. Maybe that would actually fix the issue?
Comment 33 Samuele Carcagno 2015-04-29 23:56:16 UTC
I think I've been hit by this bug too on a recent install of Debian Jessie (KDE 4.14.2). I couldn't logout and also I couldn't mount internal drives. The QT_NO_GLIB trick allowed me to logout but still I was unable to mount internal drives. The strange thing is that I had done a fresh install of Jessie on three identical workstation (except for some peripherals), and only on one of those machines this bug was present. I realized that on the problematic workstation I had installed the nvidia proprietary driver. When I replaced it with the nouveau driver the problem seemed to go away, I could mount internal drives and logout even without using the QT_NO_GLIB trick. However, the drive mounting and logout issues came back again today, so I'm not quite sure the nvidia driver has much to do with it. Sorry for the confusing bug report, but it seems really difficult to pinpoint it to something precise. Does anyone know if a bug report for this has been filed on the Debian bug tracker?
Comment 34 Axel V 2015-05-05 17:54:15 UTC
I'm experiencing this bug for quite some time as well, on Archlinux, currently kdelibs 4.14.7-1.
Comment 35 William Linna 2015-05-06 06:56:30 UTC
I noticed that when I use "Automatically Started Applications" in System Settings to autostart IM Contacts (ktp-contactlist %u), other programs won't start.

However, when I close the IM Contacts window, all other programs start (IM Contacts is first in list). Also, if I haven't closed IM contacts myself and log out, all other programs start.
Comment 36 Alexis Kauffmann 2015-05-22 23:37:40 UTC
Same problem afeter upgrade from Debian Wheezy to Jessie: clicking on shutdown does not turn off the computer.
Comment 37 Tomasz Figa 2015-07-02 12:54:03 UTC
I'm experiencing an issue looking exactly the same as described in this bug, but on latest Plasma 5 git master, since more than 5 days. This is happening on two systems with different graphics stacks, so I'd probably eliminate any GPU related issues.

** My System **
OS: Gentoo ~amd64 (default/linux/amd64/13.0/desktop/plasma/systemd profile)
GPU: System #1 - Nvidia GTX970 (binary drivers); System #2 - Intel HD 5500 (Broadwell)
Kernel: Linux 4.1.0-gentoo
Comment 38 Tomasz Figa 2015-07-02 12:55:05 UTC
Created attachment 93456 [details]
Plasma 5 boot log

Please let me know if any other information would be useful.
Comment 39 Tomasz Figa 2015-07-02 12:59:39 UTC
I forgot to note that adding "QT_NO_GLIB=1; export QT_NO_GLIB;" to .xprofile doesn't seem to change anything. In addition, which I believe might be related, there is a long delay in startup sequence with splash screen stuck with progress bar at 100%, which can be observed in the log I attached (between 21:38:24 and 21:38:50).
Comment 40 AnAkkk 2015-07-02 13:02:26 UTC
If QT_NO_GLIB doesn't fix it, I guess you have a different issue then, or that it's wrong to put it in .xprofile and should be put in a file that is parsed before SDDM/KDE starts.
Comment 41 Tomasz Figa 2015-07-02 13:21:34 UTC
(In reply to AnAkkk from comment #40)
> If QT_NO_GLIB doesn't fix it, I guess you have a different issue then, or
> that it's wrong to put it in .xprofile and should be put in a file that is
> parsed before SDDM/KDE starts.

Also tried the original method with /etc/profile.d/qt-no-glib.sh and even though I can verify that QT_NO_GLIB=1 is exported, it still doesn't help. I'll set up a new bug then.
Comment 42 AnAkkk 2015-07-22 22:22:10 UTC
Is there any chance someone could finally take a look at this?
It's been open for almost two years, and I have this bug every time I boot my laptop, plasmashell doesn't launch at all, I have to reboot it and retry until it works, it's very annoying :(
Comment 43 ulosggs 2015-07-23 14:53:40 UTC
Still buggy. No further fix??
Comment 44 AnAkkk 2015-07-30 11:14:44 UTC
I am now using this to work around the issue (at least for plasmashell):
https://github.com/eliasp/plasma-workspace-units
Comment 45 AnAkkk 2015-08-17 09:28:12 UTC
Well what I've said in my previous comment only work around the issue for plasmashell. Autostart still fails for other applications, and logout/shutdown/reboot doesn't work.

@David Faure, any idea how progress could be made on this bug? This basically break the whole desktop for some people.
Comment 46 Kevin Kofler 2015-08-17 10:16:37 UTC
In Fedora, we still ship this workaround:
http://pkgs.fedoraproject.org/cgit/kf5-kinit.git/tree/kinit-5.10.0-klauncher-qt_no_glib.patch
Comment 47 AnAkkk 2015-08-17 10:30:17 UTC
That workaround works, unfortunately Arch doesn't want to ship it because KDE developers don't want to accept it.
Comment 48 Kevin Kofler 2015-08-17 19:17:47 UTC
Then I can only suggest switching to a more helpful distribution.
Comment 49 AnAkkk 2015-08-17 19:20:12 UTC
Well, upstream is to blame as well, I guess. This issue has been known for years and that workaround has been used for a long time in Fedora as well, so it could have least been included in kinit until a proper fix can be found (if ever).
Comment 50 David Faure 2015-09-11 16:52:54 UTC
*** Bug 252068 has been marked as a duplicate of this bug. ***
Comment 51 David Faure 2015-09-11 16:59:21 UTC
Well, OK, disabling the glib event loop in klauncher doesn't sound like a bad idea then, given that nobody will dig into the glib event loop to fix this.

I'm applying the patch to KDE/4.14 and KF >= 5.15.

I'm hoping at some point the whole desktop autostart stuff moves from kded to ksmserver though, it has nothing to do in KF5 itself.
Comment 52 David Faure 2015-09-11 17:02:47 UTC
Git commit a5d9c1d5529b8eed660545ff40c02ea63a94000a by David Faure.
Committed on 11/09/2015 at 17:02.
Pushed by dfaure into branch 'KDE/4.14'.

Disable glib event loop in klauncher, since it triggers a nasty bug.

("autostart never finishes, ksmserver ignores logout/shutdown")

M  +11   -0    kinit/klauncher_main.cpp

http://commits.kde.org/kdelibs/a5d9c1d5529b8eed660545ff40c02ea63a94000a
Comment 53 David Faure 2015-09-11 17:11:41 UTC
Git commit 40c2bf7a551e379cbb61bd9491618031d7a6f8a6 by David Faure.
Committed on 11/09/2015 at 17:05.
Pushed by dfaure into branch 'master'.

Disable glib event loop in klauncher, since it triggers a nasty bug.

("autostart never finishes, ksmserver ignores logout/shutdown")
FIXED-IN: 5.15

M  +11   -0    src/klauncher/klauncher_main.cpp

http://commits.kde.org/kinit/40c2bf7a551e379cbb61bd9491618031d7a6f8a6
Comment 54 Kevin Kofler 2015-09-11 17:29:16 UTC
The logic in the patch you applied to 4.14 is inverted:
+   const bool wasQtNoGlibSet = qgetenv("QT_NO_GLIB").isEmpty();
This should be:
+   const bool wasQtNoGlibSet = !qgetenv("QT_NO_GLIB").isEmpty();
Comment 55 David Faure 2015-09-11 20:33:26 UTC
Eek too many negations indeed. Thanks for spotting, fixed.
Comment 56 Thomas Lübking 2015-10-10 07:50:50 UTC
*** Bug 347206 has been marked as a duplicate of this bug. ***
Comment 57 nazgul17@gmail.com 2015-11-09 22:26:45 UTC
The patch seems to have been submit about a month ago now. How can I update my system to use it? It is up to date, but the bug is still there... maybe I need to add a repo?
Comment 58 S. Christian Collins 2015-11-09 23:44:33 UTC
(In reply to Marco T. from comment #57)
> The patch seems to have been submit about a month ago now. How can I update
> my system to use it? It is up to date, but the bug is still there... maybe I
> need to add a repo?

What OS are you using? If you're using Kubuntu 14.04, I know this bug is fixed in the KDE 4.14.13 update that you can get by adding the Kubuntu Backports PPA (https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports).
Comment 59 nazgul17@gmail.com 2015-11-10 00:47:18 UTC
I am using Kubuntu 15.10. I run

add-apt-repository ppa:kubuntu-ppa/backports
apt-get update
apt-get upgrade

but only the following packages were updated: amarok amarok-common amarok-utils unzip
Comment 60 Peter Hewett 2016-01-16 08:36:10 UTC
Similar symptoms with Kubuntu 15.10, when attempting to log off or shutdown, ksmserver goes to 100% CPU and system does not log off or shut down.
Comment 61 paul6245 2016-01-17 01:44:14 UTC
I have had this same problem [not being able to shutdown] on a Mageia5-KDE system for sometime. This problem is marked as fixed but I cannot see exactly what the fix is. If it is from the comment 3:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.11.3-klauncher-no-glib.patch
then how exactly do you apply it? If it is in one of the other 60 comments then please explain clearly what you have to do. I also know someone who has this problem on a Kubuntu system.
Comment 62 Rex Dieter 2016-01-17 02:49:07 UTC
See comment #53 for when and where the fix was committed
Comment 63 paul6245 2016-01-18 03:30:47 UTC
(In reply to Rex Dieter from comment #62)
> See comment #53 for when and where the fix was committed

Thanks Rex, but what does comment 53 actually mean. How do I use it to fix this shutdown problem?
Comment 64 paul6245 2016-01-18 03:33:56 UTC
(In reply to Rex Dieter from comment #62)
> See comment #53 for when and where the fix was committed

Thanks Rex, but what does comment 53 actually mean. How do I use it to fix this shutdown problem?
Comment 65 Rex Dieter 2016-01-18 03:52:19 UTC
http://commits.kde.org/kinit/40c2bf7a551e379cbb61bd9491618031d7a6f8a6

was the patch committed to kinit framework, which was included in time for kde frameworks 5.15 release.  Easiest thing to do would be to upgrade to kf5-5.15
https://www.kde.org/announcements/kde-frameworks-5.15.0.php
or newer, and see if that helps.

If your distro doesn't provide kf5-5.15 or newer, ask them to include the patch/fix referenced here in their kinit builds.  (Sorry, I cannot give detailed instructions on how to do your own patched builds, that's more complicated and often specific to each distro).

If kinit-5.15 or newer doesn't fix things, you're likely hitting some different issue than is documented here.
Comment 66 Peter Hewett 2016-01-20 07:14:58 UTC
Similar symptoms with Kubuntu 15.10, which has these versions;
 $ dpkg -l | grep -i kinit
ii  kinit                                         5.15.0-0ubuntu1                            amd64        process launcher to speed up launching KDE applications
$ dpkg -l | grep -i kdelib
ii  kdelibs-bin                                   4:4.14.13-0ubuntu1                         amd64        core executables for KDE Applications
ii  kdelibs5-data                                 4:4.14.13-0ubuntu1                         all          core shared data for all KDE Applications
ii  kdelibs5-plugins                              4:4.14.13-0ubuntu1                         amd64        core plugins for KDE Applications
ii  libkf5kdelibs4support-data                    5.15.0-0ubuntu1                            all          Porting aid from KDELibs4.
ii  libkf5kdelibs4support5:amd64                  5.15.0-0ubuntu1                            amd64        Porting aid from KDELibs4.
ii  libkf5kdelibs4support5-bin                    5.15.0-0ubuntu1                            amd64        Porting aid from KDELibs4.

According to comment #65 etc, version 5.15 should have this fixed. Is that right?

In Kubuntu system settings, the driver manager offers 3 display drivers;
 - nvidia 352 (recommended)
 - nvidia 352-updates
 - x.org nouveau display driver
I have tried with all three drivers (with a reboot between changes) and the freeze-on-shutdown symptoms occur with each of the nvidia drivers, but not (so far) with the x.org driver.
Comment 67 Kevin Kofler 2016-01-20 13:16:23 UTC
Then you are not seeing this bug, but a completely different bug with the same symptoms. This bug was fixed in 5.15, which you already have.

And IMHO the bug is really that Kubuntu "recommends" the buggy proprietary drivers.
Comment 68 gustavo 2016-01-20 22:46:54 UTC
Seems odd that a logout button that doesn't work may be due to a buggy driver - if that is the case it is still a bug on KDE because a logout button should work with any driver that can paint pixels, even the vesa driver. This is probably a race condition on KDE that is exposed by a driver which is being called buggy, rather than a bug on the driver itself.
Comment 69 Jan Wiele 2016-01-20 23:09:54 UTC
Perhaps this is fixed with the new nvidia beta driver (361.18)? This driver also fixes a hang in konsole (https://bugs.kde.org/show_bug.cgi?id=343803). Just an idea, not tested.