kcrash, fork, and stdout/stderr

[Michael Pyne]

On Sun, Dec 03, 2017 at 11:54:21AM +0100, David Faure wrote:
> I'm trying to fix a bug (caught by CI) where KCrash, with the AutoRestart flag,
> restarts the crashing process directly (fork+execve) rather than via kdeinit.
> 
> The first process then exits, and whenever the child writes to stderr, it gets 
> a SIGPIPE. Oops.
> 
> How do I set things up so that the child's stderr is basically what the 
> parent's stderr was, in a way that works even if the parent exits?
> 
> I'm guessing something with dup() or dup2(), possibly?

This should already work, unless the O_CLOEXEC flag has been set on the
file descriptor for stderr.  The kernel should duplicate open
descriptors on fork(2), and exec(2) should maintain its association to
any already-open descriptors.

In that sense, calls like dup(2) are more often used to try to reconnect
open descriptors onto more appropriate file descriptors (e.g. to have
stdout and stderr refer to the same file descriptor) than to act as a
'refcount' for the underlying descriptor.

But, which process was the one writing to the terminal?  Do we know that
the destination of stderr was a PTY instead of being filtered through
some kind of kdeinit magic?  If there's a filter pipeline involved in
stderr processing then the whole chain would need to still be present
after fork/exec, not just the child.

All this makes me wonder if it wouldn't be possible (and preferable) to
have kdeinit handle the restart if it was responsible for the initial
launch.

Regards,
 - Michael Pyne