search

ninja-build / ninja

a small build system with a focus on speed
https://ninja-build.org/
Apache License 2.0
11.14k stars 1.59k forks source link

Signal handling does not work as expected #1241

Open dcolascione opened 7 years ago

dcolascione commented 7 years ago

Ninja on POSIX systems currently puts children in their own process group. This policy causes a variety of problems, since ninja doesn't perfectly forward signals to children --- for example, C-z in the terminal sends a SIGTSTP (and then SIGSTOP) to ninja, but since ninja doesn't do anything special for SIGTSTP, the compilation jobs keep running. SIGINT frequently doesn't interrupt compilation jobs either.

In GNU Make, all of these interactions work as you'd expect.

Why do we need to put subprocesses in their own process group? This whole issue disappears if we don't put children in their own process groups, let them inherit the controlling terminal, and allow signal propagation to work normally.

nicolasdespres commented 7 years ago

See #744 for SIGSTP For SIGINT check #893 and make sure your ninja includes the referred patch.

jhuels commented 2 years ago

Found a potentially related signal issue today. If you're piping the ninja output to something that closes the pipe, e.g. grep -q, it can return non-zero status. Perhaps this is what you want? Most programs ignore the SIGPIPE here.

$ cmake --build . --target help  | grep -q foo
SIGPIPE
CMake Error: Generator: execution of make failed. Make command was: ninja -j 6 help &&