I find the implementation of the function "sighandler" questionable. https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/c7fc5ed96143d91e16787a7e231f2c87e9fa2df5/entry/ksmserver/server.cpp#L527 1. No meaningful data processing is performed for "SIGHUP". Should any configuration file be reread here? 2. How do you think about to perform program clean-up outside the signal handling context? https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers http://stackoverflow.com/questions/4812491/how-to-deal-with-sigint
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
(In reply to Andrew Crouthamel from comment #1) The software situation was improved a bit with the commit “Sanitize signal handling in ksmserver” from 2018-04-13. https://github.com/KDE/plasma-workspace/commit/eb6e261979842e158dd48b1b1a32d3ae653c4389 I find that a few software development concerns remain. * The data type “sig_atomic_t” should be used for the variable “wake_up_socket”. * Is the data processing for “SIGHUP” still questionable?
>* The data type “sig_atomic_t” should be used for the variable “wake_up_socket”. Technically yes (or std::atomic if we want to be modern), though practically we're not not using that variable in parallel in the main thread except in cleanup. I'd happily accept a patch, or I can do it. >* Is the data processing for “SIGHUP” still questionable? Doesn't seem to do anything useful, it was there since the initial commit. I guess the author probably intended to do something. Using SIGHUP for config reloading isn't something we do in any KDE apps.
(In reply to David Edmundson from comment #3) * Will a socket descriptor fit into the portable value range for the data type “sig_atomic_t”? * Will the support for system configuration reloading be added to any more software applications?
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
(In reply to Justin Zobel from comment #5) Would you like to help any more with a proper source code review? https://github.com/KDE/plasma-workspace/blob/0ecf1cbfaa583f84a53e8710af6dcdb57bf81310/ksmserver/server.cpp#L436
Feel free to submit a merge request fixing this. Otherwise I suspect it will unfortunately not get done, due to lack of resourcing.