segfault when canceling builds

[bcressey]

When I cancel a build via Ctrl-C after faac675, I've seen two different results:

   Compiling wicked v0.1.0 (/home/fedora/corekit/packages/wicked)
^C[2025-01-07T18:50:34Z INFO  twoliter::cleanup] Cleaning up temporary resources...ent(build), os(build), kubernetes-1_25(build), ecr-credential-provider-1_29(build), amazon-s...
[2025-01-07T18:50:34Z INFO  twoliter::cleanup] Done cleaning up.
make: *** [Makefile:44: build] Error 130

   Compiling open-vm-tools v0.1.0 (/home/fedora/corekit/packages/open-vm-tools)
^Cmake: *** [Makefile:44: build] Segmentation fault (core dumped)t(build), kubernetes-1_24(build), systemd(build), nvidia-container-toolkit(build), host-ctr(build), open-vm-to...

The first one is a bit surprising but the segfault is more concerning.

[cbgbt]

Thanks for the report. I believe the first is expected behavior -- the bottlerocket-core-kit Makefile is executing twoliter, which is exiting 130 when it receives SIGINT (relevant code).

The second is more concerning. I'll look into it.

[cbgbt]

I chatted with @bcressey -- I believe the first case was surprising in that it was different. These log messages also don't necessarily need to be at INFO level since they are often not actually cleaning any files.

For the segfault, this is possibly because I didn't follow signal-safety while implementing the handler -- we are deleting files while handling the signal.

"Safe" handling of signals typically involves flipping atomic integers that we then process after the signal handler completes; however, this doesn't provide us with a way to interrupt the downloading of the Bottlerocket SDK. We would need to find a way for the Rust=>golang FFI to be interruptible.

[cbgbt]

We ended up reverting the changes that caused this segmentation fault due to an issue getting twoliter to build using FFI to golang libraries and statically linking to musl.