Bug 348123

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

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.

FYI this happens only when running through startx and not using login manager.

It happens with sddm here. I don't have startx (xorg-xinit) installed.

Okay, I was better able to reproduce it with the startx though.

I'm seeing this on Fedora 22 (kf5-f.11, plasma 5.3.1) using KDM as the login manager.

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.

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.

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

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)

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

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.

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

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

To be sure, does the file snippet you created have execute permissions?  If not, it won't work.

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 <rdieter@math.unl.edu> ---
> 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.

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

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.

If you could provide any technical details on the pulseaudio problem, I'd be happy to facilitate pushing it back to pulseaudio upstream devs.

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

(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[4185]: [pulseaudio] client.c: Freed 10 "KMix"
Nov 02 18:23:23 b-movie pulseaudio[4185]: [pulseaudio] protocol-native.c: Connection died.
Nov 02 18:23:23 b-movie pulseaudio[4185]: [pulseaudio] client.c: Freed 0 "Login Session c2"

Nov 02 18:23:43 b-movie pulseaudio[4185]: [pulseaudio] core.c: We are idle, quitting...
Nov 02 18:23:43 b-movie pulseaudio[4185]: [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.

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.

Updating summary to mention kuiserver, see also comment #18 for relevant patch

(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

Odd, patch works as advertised for me.

The patch works for me as well.

OK, something else must have been at play because that patch is working for me now.  Weird.

Sorry for the noise.

Submitted to reviewboard,
https://git.reviewboard.kde.org/r/127793/

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.

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

Sorry, forgot to add fixed-in key, can expect this to be resolved when plasma-5.6.4 is released (around May 10, according to current schedule @ https://community.kde.org/Schedules/Plasma_5 )