bst build does not exit gracefully on a second CTRL-C
Summary
Doing a CTRL-C from with the user interrupt handler (the presented click dialogue) should terminate buildstream. It is terminating, however we get errors from unknown child processes, leading to ERROR messages.
- Note this behaviour is seen on native Ubuntu 19.04
Steps to reproduce
bst build hello.bst in the autotools example project
ctrl-c whilst fetching/building to get the interrupt dialogue, ctrl-c again to terminate
What is the current bug behavior?
--:--:--][96c13701][ fetch:base/alpine.bst ] START autotools/base-alpine/96c13701-fetch.18691.log
[--:--:--][96c13701][ main:base/alpine.bst ] STATUS Fetch suspending
User interrupted with ^C
Choose one of the following options:
(c)ontinue - Continue queueing jobs as much as possible
(q)uit - Exit after all ongoing jobs complete
(t)erminate - Terminate any ongoing jobs and exit
Pressing ^C again will terminate jobs and exit
Choice: [continue]: ^C
Terminating all jobs at user request
[--:--:--][96c13701][ main:base/alpine.bst ] STATUS Fetch terminating
Unknown child process pid 18691, will report returncode 255
[--:--:--][96c13701][ main:base/alpine.bst ] ERROR Internal job process unexpectedly died with exit code 255
[00:00:04][ ][ main:core activity ] WARNING Build Terminated
Pipeline Summary
Total: 3
Session: 3
Fetch Queue: processed 0, skipped 3, failed 0
Build Queue: processed 0, skipped 0, failed 0
What is the expected correct behavior?
We should handle the child watcher more gracefully so it doesn't emit an error, presumably it's the casd process child watcher in this case, with the pid being reaped early.
Edited by Tom Pollard