When sending SIGTERM to plasmashell, it terminates immediately without properly tearing down the plasmashell instance as it does when shutting it down via kquitapp5. It looks like there's no UNIX signal handling code in shell/main.cpp at all and QApplication itself doesn't seem to do anything by default in terms of UNIX signal handling.
was this handled by kapplication in the past? really seems a thing that qapplication or even qcoreapplication should do, having to write unix signal handler by hand in every ported application would be seriously not good :/
(In reply to Marco Martin from comment #1) > was this handled by kapplication in the past? I'm not really sure. Looking at some kdelibs (KDE/4.14) code, I feel like there was no generic signal handling support in kdelibs and every application did it on its own. Some comments from someone with a bit more insight/knowledge would be welcome. > really seems a thing that qapplication or even qcoreapplication should do, > having to write unix signal handler by hand in every ported application > would be seriously not good :/ I do fully agree… as the procedure on how to deal with the most common received signals is usually the same for each app, that's something which should be covered in qapplication or qcoreapplication and only special cases should be handled by the application itself.
Filed now an upstream bug for this: https://bugreports.qt-project.org/browse/QTBUG-43653 Should signal handling be implemented in plasmashell in the meanwhile or will we just wait for this to trickle down once this is hopefully implemented in QCoreApplication?
Is this needed for some systemd thing?
Created attachment 92416 [details] attachment-15010-0.html Yes and no. It makes future systemd efforts easier as one doesn't need to use an "ExecStop=/usr/bin/kquitapp5 plasmashell"-style workaround for each and every application. Besides that, shutting down gracefully on SIGTERM is just an expected behaviour of any POSIX application and QCoreApplication breaks with this principle at this point by not having a SIGTERM-handler implemented by default. Re-implementing SIGTERM-handling in each application makes IMHO no sense at all and this problem should be solved upstream. On May 4, 2015 6:04:56 PM GMT+02:00, David Edmundson <kde@davidedmundson.co.uk> wrote: > >https://bugs.kde.org/show_bug.cgi?id=339763 > >David Edmundson <kde@davidedmundson.co.uk> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |kde@davidedmundson.co.uk > Status|UNCONFIRMED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > >--- Comment #4 from David Edmundson <kde@davidedmundson.co.uk> --- >Is this needed for some systemd thing? > >-- >You are receiving this mail because: >You reported the bug.
OK, given there's now a bug upstream I'm going to close this so it's not pernamently in my "to triage" list. Pester me if it's ever holding up systemd units. Implementing it for all the daemons only wouldnt' be too ridiculous.