Bug 328571

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.

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.

This workaround appears to work for us:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.11.3-klauncher-no-glib.patch

I can confirm the patch from comment 3 fixed the issue for me. I applied the patch against kdelibs 4.11.5 on Gentoo.

I currently experience this on 4.13, Gentoo.

The workaround from comment #3 is still the only fix I'm aware of.

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

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.

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.

Created attachment 87817 [details]
Program that hangs the autostart sequence

Then what you are seeing is not this bug, but a different issue with the same symptoms.

So, should I file a new bug? I filed #327543 but it was marked as duplicate of this one.

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.

marking confirmed, fwiw, given at least several independant reporters seeing it too

OK, filed new bug #337667

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?

This might actually be the same issue as I've reported here:
https://bugs.kde.org/show_bug.cgi?id=339122

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

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.

As this bug affects KF5/Plasma 5 too, adding dfaure to the CC list since he's the maintainer.

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.

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.

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...

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 :/

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).

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

Also, there seems to have been a lot of sleuthing done on this bug here: https://bugzilla.redhat.com/show_bug.cgi?id=983110

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.

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.

Next steps towards getting a fix into the distros?

Some distros like ArchLinux don't want to fix it because there's no official upstream fix.

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?

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?

I'm experiencing this bug for quite some time as well, on Archlinux, currently kdelibs 4.14.7-1.

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.

Same problem afeter upgrade from Debian Wheezy to Jessie: clicking on shutdown does not turn off the computer.

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

Created attachment 93456 [details]
Plasma 5 boot log

Please let me know if any other information would be useful.

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).

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.

(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.

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 :(

Still buggy. No further fix??

I am now using this to work around the issue (at least for plasmashell):
https://github.com/eliasp/plasma-workspace-units

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.

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

That workaround works, unfortunately Arch doesn't want to ship it because KDE developers don't want to accept it.

Then I can only suggest switching to a more helpful distribution.

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).

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

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.

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

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

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();

Eek too many negations indeed. Thanks for spotting, fixed.

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

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?

(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).

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

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.

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.

See comment #53 for when and where the fix was committed

(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?

(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?

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.

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.

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.

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.

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.