Skip to content

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information