|Summary:||Some processes (kuiserver) are left running after exiting KDE|
|Product:||[Plasma] plasmashell||Reporter:||John Lindgren <john>|
|Component:||general||Assignee:||David Edmundson <kde>|
|Severity:||normal||CC:||bhush94, bugzilla-kde, dan, daniel, deptuch, ht990332, j, jpsinthemix, kde, paolo.pedroni, plasma-bugs, rdieter, reuben_p, rthomsen6, serhiy.int, steve, vmlinuz386|
|Latest Commit:||http://commits.kde.org/plasma-workspace/5f6a27e7754241e744cd9e92bb812da0d7f5e274||Version Fixed In:||5.6.4|
|Attachments:||Use QApplication (instead of QCoreApplication) for apps with GUI components|
Description John Lindgren 2015-05-23 01:02:28 UTC
The following processes are left running after exiting KDE: 4524 test 20 0 17.6m 0.2m 0.0 0.0 0:00.00 S dbus-launch 4525 test 20 0 33.6m 2.5m 0.0 0.1 0:00.10 S dbus-daemon 4548 test 20 0 13.9m 2.8m 0.0 0.1 0:00.00 S gam_server 4556 test 20 0 429.2m 33.0m 0.0 0.9 0:00.15 S kglobalaccel5 4567 test 20 0 655.8m 33.4m 0.0 0.9 0:00.09 S kactivitymanage 4593 test 20 0 172.1m 4.5m 0.0 0.1 0:00.00 S dconf-service 4644 test 20 0 257.5m 24.9m 0.0 0.6 0:00.04 S kuiserver Furthermore, KDE cannot be cleanly restarted until these processes are killed. Otherwise, the startup time is over 30 seconds (perhaps due to trying to communicate with the running processes?) and then eventually duplicate instances of those same processes are started. Reproducible: Always Steps to Reproduce: 1. Run startkde. 2. Exit KDE ("log out" from the system menu). 3. Attempt to start KDE again (without restarting X11). Actual Results: KDE takes over 30 seconds to start and runs new instances of the processes that were still running after exiting the first session. Expected Results: KDE should start in a timely fashion and should not run multiple instances of the same process. This could be accomplished either by shutting down all processes cleanly on logout (my preferred solution) or by correctly detecting and communicating with the still-running processes when KDE is started a second time. plasma-workspace 5.3.0-4
Comment 1 Marco Martin 2015-05-28 08:54:22 UTC
*** Bug 341332 has been marked as a duplicate of this bug. ***
Comment 2 Hussam Al-Tayeb 2015-06-09 22:59:27 UTC
only kuiserver5 stays there here. I don't have debug symbols installed so the stacktrace doesn't help but here it is. it is obviously a crash. (gdb) bt full #0 0x00007fb9254c8e70 in __poll_nocancel () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007fb91f92ac0c in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007fb91f92ad1c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007fb922ae4d1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #4 0x00007fb922a8affa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #5 0x00007fb922a92a4c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 No symbol table info available. #6 0x00007fb9257993d6 in kdemain () from /usr/lib/libkdeinit5_kuiserver5.so No symbol table info available. #7 0x00007fb92540a790 in __libc_start_main () from /usr/lib/libc.so.6 No symbol table info available. #8 0x00000000004007a9 in _start () No symbol table info available.
Comment 3 Bhushan Shah 2015-06-18 12:12:49 UTC
FYI this happens only when running through startx and not using login manager.
Comment 4 Hussam Al-Tayeb 2015-06-18 12:18:06 UTC
It happens with sddm here. I don't have startx (xorg-xinit) installed.
Comment 5 Bhushan Shah 2015-06-18 12:22:45 UTC
Okay, I was better able to reproduce it with the startx though.
Comment 6 Jason Tibbitts 2015-07-06 23:05:30 UTC
I'm seeing this on Fedora 22 (kf5-f.11, plasma 5.3.1) using KDM as the login manager.
Comment 7 John Stanley 2015-09-29 04:37:28 UTC
I'm seeing this as well with plasma-5.4.1/frameworks-5.14.0, and Qt-5.5.0 (kuiserver and systemd/sd-pam remain after every logout). Moreover, with Qt-5.6git, I'm seeing kuiserver, systemd/sd-pam, kded, and several other kde processes remaining after logout.
Comment 8 Hussam Al-Tayeb 2015-09-29 06:37:07 UTC
systemd/sd-pam will remain if you were logged onto a tty and you logged off KDE. It only exits after all you login sessions are logged off.
Comment 9 John Stanley 2015-09-29 07:09:29 UTC
(In reply to Hussam Al-Tayeb from comment #8) > systemd/sd-pam will remain if you were logged onto a tty and you logged off > KDE. It only exits after all you login sessions are logged off. I understand. But that is not the case here. I logged into kde as user A, then logged out. Then I log in via ssh as user B, do ps xa and see the kde processes mentioned (including systemd/sd-pam), all owned by user A, still running.
Comment 10 Hussam Al-Tayeb 2015-09-29 07:53:02 UTC
The KDE parts is likely something crashing on exit. While they are still running, logind still thinks you are logged on because you are logged on till your last process exits. coredumpctl should show the list of crashed items. maybe you can get backtraces that way. (coredumpctl info the_pid_of_kuiserver_from_that_list)
Comment 11 John Stanley 2015-09-29 08:47:09 UTC
(In reply to Hussam Al-Tayeb from comment #10) > The KDE parts is likely something crashing on exit. While they are still > running, logind still thinks you are logged on because you are logged on > till your last process exits. > coredumpctl should show the list of crashed items. maybe you can get > backtraces that way. > (coredumpctl info the_pid_of_kuiserver_from_that_list) The only thing crashing on logout is kactivitymanagerd (same as https://bugs.kde.org/show_bug.cgi?id=348194, and presumably related to https://bugreports.qt.io/browse/QTBUG-35977). However, while I'm seeing kactivitymanagerd crash on most logouts, it doesn't always crash, and when it doesn't I still see the unterminated processes noted. I'll see if I can come with some more info on this, but it may take several days. Thanks much for your time.
Comment 12 John Stanley 2015-09-30 23:15:51 UTC
I suppose the systemd/sd-pam is a systemd issue, so forget about that one. So, right now I just have kuiserver5 processes remaining after logout and never killed. If I repeatedly login and logout, they are never killed so, eg, if I login and logout 4 times, on the 4'th logout I have 4 copies of kuiserver5 running for that user. Aside from kactivitymanagerd, nothing is crashing on logouts, and (w/kactivitymanagerd effectively disabled, I still see the problem). At this point, given this issue, plus broken kactivitymanagerd, plus broken session management, plus lack of pure-kf5 apps, I 'm leaning towards moving back to Qt4/kde4, but I'd rather avoid this as KF5 does look nice and window effects are working nicely.
Comment 13 Rex Dieter 2015-10-07 21:17:06 UTC
At least for the kuiserver5-still-running issue, one workaround is to create an executable snippet: ~/.config/plasma-workspace/shutdown/kuiserver5.sh that contains: qdbus org.kde.kuiserver /MainApplication org.qtproject.Qt.QCoreApplication.quit
Comment 14 John Stanley 2015-10-14 10:19:18 UTC
(In reply to Rex Dieter from comment #13) > At least for the kuiserver5-still-running issue, one workaround is to create > an executable snippet: > ~/.config/plasma-workspace/shutdown/kuiserver5.sh > that contains: > qdbus org.kde.kuiserver /MainApplication > org.qtproject.Qt.QCoreApplication.quit Unfortunately, doing this has no effect for me; kuiserver5 processes remain running.
Comment 15 Rex Dieter 2015-10-14 11:49:07 UTC
To be sure, does the file snippet you created have execute permissions? If not, it won't work.
Comment 16 Hussam Al-Tayeb 2015-10-14 11:57:21 UTC
On Wed, 2015-10-14 at 11:49 +0000, Rex Dieter wrote: > https://bugs.kde.org/show_bug.cgi?id=348123 > > --- Comment #15 from Rex Dieter <email@example.com> --- > To be sure, does the file snippet you created have execute > permissions? If > not, it won't work. > Perhaps the process crashed? the last time I saw this, I got a bt from the crashed process. But this looks fixed in 5.4.x for me.
Comment 17 John Stanley 2015-10-14 21:38:29 UTC
(In reply to John Stanley from comment #14) > (In reply to Rex Dieter from comment #13) > > At least for the kuiserver5-still-running issue, one workaround is to create > > an executable snippet: > > ~/.config/plasma-workspace/shutdown/kuiserver5.sh > > that contains: > > qdbus org.kde.kuiserver /MainApplication > > org.qtproject.Qt.QCoreApplication.quit > > Unfortunately, doing this has no effect for me; kuiserver5 processes remain > running. oops, my mistake (didn't make in exec); yes this works, all user processes are removed, including systemd/sd-pam (which I think is not a systemd issue but remains running because it thinks the session is still active). Thanks for the workaround.
Comment 18 John Stanley 2015-11-02 20:41:15 UTC
Created attachment 95270 [details] Use QApplication (instead of QCoreApplication) for apps with GUI components The attached patch fixes the 'lingering kuiserver processes after logout' issue. In debugging this I found that when using QCoreApplication, the kuiserver was not being properly terminated and the associated dbus service never unregistered. Also, lingering pulseaudio processes are due to a bug in pulseaudio termination (what a surprise), and not to kde (and they terminate after logout after a few seconds). hope this helps, thanks to all.
Comment 19 Rex Dieter 2015-11-02 21:48:20 UTC
If you could provide any technical details on the pulseaudio problem, I'd be happy to facilitate pushing it back to pulseaudio upstream devs.
Comment 20 John Stanley 2015-11-02 22:57:26 UTC
(In reply to Rex Dieter from comment #19) > If you could provide any technical details on the pulseaudio problem, I'd be > happy to facilitate pushing it back to pulseaudio upstream devs. I'll look into it a bit in the next few days.. but now I'm trying to finish a fix for the session management issue https://bugs.kde.org/show_bug.cgi?id=346768 (I have a tentative fix for 346768 which is probably good enough for me, but I'm not completely happy with it, so I need to play with it a bit more).
Comment 21 John Stanley 2015-11-03 07:08:13 UTC
(In reply to John Stanley from comment #20) > (In reply to Rex Dieter from comment #19) > > If you could provide any technical details on the pulseaudio problem, I'd be > > happy to facilitate pushing it back to pulseaudio upstream devs. > > I'll look into it a bit in the next few days.. but now I'm trying to finish > a fix for the session management issue > https://bugs.kde.org/show_bug.cgi?id=346768 (I have a tentative fix for > 346768 which is probably good enough for me, but I'm not completely happy > with it, so I need to play with it a bit more). Here's a summary of the issue along with a resolution (looks like its not really a bug after all): For a vanilla pulseaudio-7.1 installation, the pulse daemon remains running for some time after user session logout (after logout, the user processes pulseaudio and sd-pam(systemd) remain. The processes do in fact terminate some 15+ seconds later. You can see this in the (loglevel info) logs, eg, Nov 02 18:23:23 b-movie pulseaudio: [pulseaudio] client.c: Freed 10 "KMix" Nov 02 18:23:23 b-movie pulseaudio: [pulseaudio] protocol-native.c: Connection died. Nov 02 18:23:23 b-movie pulseaudio: [pulseaudio] client.c: Freed 0 "Login Session c2" Nov 02 18:23:43 b-movie pulseaudio: [pulseaudio] core.c: We are idle, quitting... Nov 02 18:23:43 b-movie pulseaudio: [pulseaudio] main.c: Daemon shutdown initiated. I thought about fixing this with a simple patch, eg, --- pulseaudio-7.1.old/src/modules/module-systemd-login.c 2015-09-10 00:51:41.000000000 -0400 +++ pulseaudio-7.1.new/src/modules/module-systemd-login.c 2015-11-02 20:53:55.338622526 -0500 @@ -94,6 +94,9 @@ pa_log_debug("Removing session %s", session->id); + /* Presumably a logout; no need for idle waits */ + session->client->core->exit_idle_time = 0; + pa_client_free(session->client); pa_xfree(session->id); pa_xfree(session); but then (stupid me) I had a look at the pulse-daemon.conf manpage, which contains: IDLE TIMES exit-idle-time= Terminate the daemon after the last client quit and this time in seconds passed. Use a negative value to disable this feature. Defaults to 20. The --exit-idle-time command line option takes precedence. So, in /etc/pulse/daemon.conf, setting exit-idle-time = 0 solves the problem. Note that setting it to a negative value effectively sets the idle wait to infinity (the daemon never terminates on its own). So, this is not really a bug after all, but I am curious about the intended purpose of this idle wait time and whether there are negative repercussions to setting it to zero.
Comment 22 John Lindgren 2016-04-02 03:05:46 UTC
The situation is somewhat better with KDE 5.6.1, probably due to the fix for bug 352251. About the same set of processes are still left running after exiting KDE, but starting KDE a second time doesn't delay nor start duplicates any more; it seems to reuse the already running processes.
Comment 23 Rex Dieter 2016-04-27 21:49:01 UTC
Updating summary to mention kuiserver, see also comment #18 for relevant patch
Comment 24 Steve Youngs 2016-04-28 07:17:06 UTC
(In reply to John Stanley from comment #18) > Created attachment 95270 [details] > Use QApplication (instead of QCoreApplication) for apps with GUI components I just tried this patch, and with it KDE won't start. It goes no further than the splash screen. This was with plasma-workspace v5.6.3-233-g37a70c0
Comment 25 Rex Dieter 2016-04-28 10:43:40 UTC
Odd, patch works as advertised for me.
Comment 26 Paolo Pedroni 2016-04-28 11:57:57 UTC
The patch works for me as well.
Comment 27 Steve Youngs 2016-04-29 00:29:48 UTC
OK, something else must have been at play because that patch is working for me now. Weird. Sorry for the noise.
Comment 28 Rex Dieter 2016-04-29 16:23:39 UTC
Submitted to reviewboard, https://git.reviewboard.kde.org/r/127793/
Comment 29 Rex Dieter 2016-04-29 16:32:25 UTC
Question posed in reviewboard: "Which part of ProgressListModel uses a UI?" John Stanley, the patch comment is from you, can offer some advice/guidance here? The answer is not clear to me.
Comment 30 Rex Dieter 2016-04-29 16:34:59 UTC
Git commit 5f6a27e7754241e744cd9e92bb812da0d7f5e274 by Rex Dieter. Committed on 29/04/2016 at 16:34. Pushed by rdieter into branch 'Plasma/5.6'. kuiserver: use QApplication rather than QCoreApplication As GUI elements are present in ProgressListModel, use QApplication rather than QCoreApplication to ensure a GUI eventloop. REVIEW: 127793 M +1 -1 kuiserver/main.cpp http://commits.kde.org/plasma-workspace/5f6a27e7754241e744cd9e92bb812da0d7f5e274