If kdesud is running when a user logs out of their session under systemd, it appears to send the kdesud process (and presumably all other user processes too) a HUP and then a TERM signal in quick succession.  This is even without logind's "KillUserProcesses" option.  The problem can also be reproduced without systemd by manually sending these two signals to the kdesud process.

The problem is that the signals invoke a nested signal handler, the second of which hangs on a mutex within KDebug().


Reproducible: Sometimes

Steps to Reproduce:
1.  Start a login session, not necessarily under systemd, and do something which will invoke a kdesu prompt.

2.  Execute "kill -HUP <pid>; kill -TERM <pid>" where <pid> is the process ID of the kdesud process.

3.  Observe that the kdesud process has not exited.


Actual Results:  
The kdesud process does not exit, and can only be killed with a KILL.


Expected Results:  
The kdesud process should exit so that the user's session can be properly closed.


Attaching to the hung kdesud process produces the following backtrace:

GNU gdb (Gentoo 7.7.1 p1) 7.7.1
Attaching to process 31128
Reading symbols from /usr/kde4/lib64/kde4/libexec/kdesud...done.
0x00007fbebffb63c9 in syscall () from /lib64/libc.so.6
(gdb) where
#0  0x00007fbebffb63c9 in syscall () from /lib64/libc.so.6
#1  0x00007fbec0d2fe15 in _q_futex (val2=0, addr2=0x0, timeout=0x0, val=2, op=0, 
    addr=0x1af62c0) at thread/qmutex_unix.cpp:99
#2  QMutexPrivate::wait (this=this@entry=0x1af62c0, timeout=timeout@entry=-1)
    at thread/qmutex_unix.cpp:113
#3  0x00007fbec0d2c58d in QMutex::lockInternal (this=<optimized out>)
    at thread/qmutex.cpp:450
#4  0x00007fbec0d2c6c9 in QMutex::lock (this=this@entry=0x1af6410) at thread/qmutex.cpp:177
#5  0x00007fbec26b5dc3 in QMutex::lockInline (this=this@entry=0x1af6410)
    at /usr/kde4/include/QtCore/qmutex.h:198
#6  0x00007fbec26b5e02 in QMutexLocker::QMutexLocker (this=0x7fff33e2b5b0, m=0x1af6410)
    at /usr/kde4/include/QtCore/qmutex.h:109
#7  0x00007fbec26b5685 in KDebug::hasNullOutput (type=QtDebugMsg, condition=false, 
    condition@entry=true, area=1205, enableByDefault=255, enableByDefault@entry=true)
    at /ws/trunk/kdelibs/kdecore/io/kdebug.cpp:831
#8  0x0000000000404cb8 in KDebug::hasNullOutputQtDebugMsg (area=area@entry=1205)
    at /usr/kde4/include/kdebug.h:272
#9  0x0000000000404466 in signal_exit (sig=15)
    at /ws/trunk/kdebase/kderuntime/kdesu/kdesud/kdesud.cpp:148
#10 <signal handler called>
#11 0x00007fbebffab6e5 in __lxstat64 () from /lib64/libc.so.6
#12 0x00007fbebff13926 in realpath () from /lib64/libc.so.6
#13 0x00007fbec0e0529f in realpath (__resolved=0x0, __name=<optimized out>)
    at /usr/include/bits/stdlib.h:48
#14 QFileSystemEngine::canonicalName (entry=..., data=...)
    at io/qfilesystemengine_unix.cpp:271
#15 0x00007fbec0dbb0c5 in QFileInfoPrivate::getFileName (this=0x1b142a0, 
    name=name@entry=QAbstractFileEngine::CanonicalName) at io/qfileinfo.cpp:60
#16 0x00007fbec0dbc896 in QFileInfo::canonicalFilePath (this=this@entry=0x7fff33e2bd60)
    at io/qfileinfo.cpp:544
#17 0x00007fbec26754be in KConfigIniBackend::setFilePath (this=0x1b13a20, file=...)
    at /ws/trunk/kdelibs/kdecore/config/kconfigini.cpp:568
#18 0x00007fbec26749ef in KConfigBackend::create (componentData=..., file=..., sys=...)
    at /ws/trunk/kdelibs/kdecore/config/kconfigbackend.cpp:89
#19 0x00007fbec2667127 in KConfigPrivate::changeFileName (this=this@entry=0x1af6980, 
    name=..., type=type@entry=0x7fbec278b5ed "config")
    at /ws/trunk/kdelibs/kdecore/config/kconfig.cpp:580
#20 0x00007fbec2667d7c in KConfig::KConfig (this=0x1ae7920, file=..., mode=..., 
    resourceType=0x7fbec278b5ed "config")
    at /ws/trunk/kdelibs/kdecore/config/kconfig.cpp:245
#21 0x00007fbec26b782f in KDebugPrivate::configObject (this=this@entry=0x1af6410)
    at /ws/trunk/kdelibs/kdecore/io/kdebug.cpp:392
#22 0x00007fbec26b797a in KDebugPrivate::areaOutputMode (this=this@entry=0x1af6410, 
    type=type@entry=QtDebugMsg, area=1205, enableByDefault=enableByDefault@entry=true)
    at /ws/trunk/kdelibs/kdecore/io/kdebug.cpp:334
#23 0x00007fbec26b7cde in KDebugPrivate::areaData (this=0x1af6410, type=QtDebugMsg, 
    num=1205, enableByDefault=<optimized out>)
    at /ws/trunk/kdelibs/kdecore/io/kdebug.cpp:430
#24 0x00007fbec26b56e5 in KDebug::hasNullOutput (type=28271668, condition=240, 
    condition@entry=true, area=1205, enableByDefault=255, enableByDefault@entry=true)
    at /ws/trunk/kdelibs/kdecore/io/kdebug.cpp:842
#25 0x0000000000404cb8 in KDebug::hasNullOutputQtDebugMsg (area=area@entry=1205)
    at /usr/kde4/include/kdebug.h:272
#26 0x0000000000404466 in signal_exit (sig=1)
    at /ws/trunk/kdebase/kderuntime/kdesu/kdesud/kdesud.cpp:148
#27 <signal handler called>
#28 0x00007fbebffb32c3 in select () from /lib64/libc.so.6
#29 0x0000000000403d7c in main (argc=<optimized out>, argv=<optimized out>)
    at /ws/trunk/kdebase/kderuntime/kdesu/kdesud/kdesud.cpp:350
(gdb)

The relevant code in kderuntime/kdesu/kdesud/kdesud.cpp is:

void signal_exit(int sig)
{
    kDebug(1205) << "Exiting on signal " << sig << "\n";
    kdesud_cleanup();
    exit(1);
}

int main(int argc, char *argv[])
{
    // Signal handlers
    struct sigaction sa;
    sa.sa_handler = signal_exit;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGHUP, &sa, 0L);
    sigaction(SIGINT, &sa, 0L);
    sigaction(SIGTERM, &sa, 0L);
    sigaction(SIGQUIT, &sa, 0L);

Suggested fix (not tested yet): set the sa.sa_mask to block other signals during the execution of the signal handler - if a later one is lost it doesn't matter, because the daemon is going to exit anyway.

Have not tested this on Frameworks yet, but the code in tier3/kdesu/src/kdesud/kdesud.cpp appears to be the same.  It may be that qCDebug() does not use a mutex in which case this problem will not happen.