Re: Triggering graceful bitbake shutdown

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi,

On Tue, 2016-03-01 at 14:50 +0200, Tanu Kaskinen wrote:
> I wrote a small script that runs bitbake sequentially with multiple
> MACHINE values. Sometimes I want to stop it with ctrl-c before it has
> finished, but it didn't work properly out-of-the box when running
> bitbake under the script (my script would not wait for bitbake to
> exit,
> and bitbake threw some backtrace too). I then modified SIGINT
> handling
> in my script so that it forwards the signal to bitbake and then waits
> for bitbake to exit. The problem is that bitbake ignores SIGINT. The
> UI
> handles python's KeyboardInterrupt exception, but that exception
> doesn't get raised when bitbake runs under my script. I don't know
> what
> triggers KeyboardInterrupt in normal conditions, since SIGINT doesn't
> seem to be sufficient, does python perhaps monitor stdin to catch the
> actual ctrl-c keypress?
> 
> Anyway, sending SIGTERM instead of SIGINT "works". However, the
> SIGTERM
> handler shuts down bitbake immediately rather than waiting for the
> current tasks to finish. Is that less safe than the normal ctrl-c
> handling? If the immediate shutdown is equally safe, then I have no
> problem, but if SIGTERM can cause state corruption so that resuming
> later doesn't work reliably, then I'd like to have some way for
> triggering graceful bitbake shutdown from my script. Any suggestions?
> 
> Or maybe there is already some way to run bitbake for multiple
> MACHINEs, and I don't need to write any script myself?

I'm curious which bitbake process you're sending SIGINT to. If its the
knotty UI, it should shutdown gracefully. Other pieces of the system
ignore SIGINT since we really want the UI to do it. The behaviour you
mention above sounds suboptimal though.

I'm a bit pushed for time with the release stablisation at the moment
but would love to see if there is something better we can do here...

Cheers,

Richard