How are service bound containers terminated?

[charred pivot]

I just had a quick question: How are containers, which are bound as services, ultimately terminated?

Is it via a particular signal? i.e. SIGTERM or SIGKILL?

I ask as I have been experimenting with collecting the new cover directory data with Go 1.20.
My foreground container is my test suite and my service is bound to it.
I want to collect up the coverage data from this bound container.

I have found that the cover metadata is in my resulting cache volume, however, not the counters (the useful bit).
Reading the docs on the new cover features, it says that cover data will only be output when the program returns from main or os.Exit is called. My latest suspicion is to do with how Dagger may be terminating these containers.

[elfin crypt]

I'd assume that when services sto through buidlkit cancelation, proper SIGTERM / SIGSTOP flow is followed. Having said that, surely @viral mango knows more about how that works 🙌

[charred pivot]

I have successfully gotten my container to write out coverage counters, however, I actually went to the extent of adding an endpoint which I can invoke via wget it in the foreground container before letting Dagger tear it down. That worked.
There could be something silly going on in my program causing it to panic exit via some non standard way though.
But would like to rule out a non-trapable signal exit.

[viral mango]

@charred pivot I'm pretty sure it's a SIGKILL unfortunately.

[charred pivot]

That would make sense with what I think I am observing. Darn, oh well, I will have to keep doing what I am doing then. No worries.

[elfin crypt]

@charred pivot take into account that service containers are terminated 10 seconds after it was last used. Maybe that can help you perform some task before it effectively gets terminated

[viral mango]

👍 will keep this in mind and watch for other folks needing something similar. I personally like the aggressive teardown since it keeps things fast, but yeah, it's a bit counterproductive in this case.

we could add an option, but it'd require an upstream change to Buildkit. not a blocker in any sense, just giving context

[charred pivot]

Thanks guys! Makes total sense.
I need to make sure that I am no longer going to be invoking any endpoints on my service before I tell it to write out cover counters.
So the way I have it with an endpoint which triggers the write is good enough for now.
I just curl/wget it from the foreground after running my integrations tests and then let it get cancelled.

[elfin crypt]

@viral mango interesting.. speaking from inexperience here, but I imagined that SIGKILL was invoked in this case because we're basically cancelling the buildkit context. Doesn't buildkit have a specific stopAPI to perform this gracefully?