| sebas |
| KWin | |
| Plasma |
Normally the xclipboardsyncer should terminate because the socket
becomes unusable. But we have reports of it not really going down and
running amok.
In order to prevent such situations this change registers SIGTERM to be
sent to xclipboardsyncer when the parent process (that is kwin_wayland)
dies in whatever way. This ensures that xclipboardsyncer cannot become
an orphan.
BUG: 371862
Only compile tested, no way to get into the problematic situation
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
If the child survives the parent that normally means it's forked at some point and the fork will clear the flag - anyway:
Kai says the process knocks out gdb - is it a zombie process (indicated by "D", cannot be stopped or killed, let alone being terminated) and/or is the socket actually closed or still around?
clear which flag? The idea of PDEATHSIG is to get signalled when the parent dies, that is when the ppid changes to 1.
This boils down to the question why the process is still lingering around. If the only parent/child link is actually the socket, then it's more likely to zombie around on a bad socket.
In this case you can fire as many signals as you want - they'll never be handled (the process isn't interruptable)
Otherwise QProcess would setup the child process in a way to die with the parent anyway. If that doesn't happen, the child may have been forked off at some point and in that case lost the deathsig/sigterm connection (according to the prctl manpage, I've actually never tried that myself)
tl;dr - somebody needs to test this and ideally check *how* the process refuses to die (but the gdb hassle seems to indicate a zombie) and the process table at this point.