Add manual steps describing how to check launcher behavior regarding POSIX signals

[KtorZ]

Issue Number

#8

Overview

• I have added some manual steps to verify that SIGINT and SIGTERM are handled properly

Comments

It's more about having that written that so that, we won't forget to test it upon releases!

[piotr-iohk]

This is nice.
In order to make it more complete maybe we could add also cases for:

• SIGQUIT -> Ctrl + \
• SIGKILL -> kill -9

cf: https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html

[KtorZ]

Sure 👍, though, keep in mind that we do not handle the SIGKILL for now. This one is a bit tricky because in practice, we can't put a signal handler since the SIGKILL with forcefully and immediately terminates the process (which is, the expected semantic for a SIGKILL).

We had a chat this morning with @rvl about a way to handle that by having a shared socket between the supervisor process and its children. When the supervisor gets closed, one end of the socket will get closed as well, cascading to the child which will also terminate. For now, I'll mention the current behavior in the steps, and we can refine it later for the SIGKILL if we want to.

[piotr-iohk]

Yes, I noticed some comments about SIGKILL on other PRs later on, after putting this comment.

Just thinking If we won't support SIGKILL than maybe it would be worth putting this in some user facing documentation as a known issue/limitation/behaviour (not sure where, API doc?).

[KtorZ]

Well, it's not that we don't support SIGKILL, we do. But the semantic of SIGKILL doesn't allow us to do any clean-up after receiving it. So, if one kills the launcher, one doesn't kill the sub-processes the launcher has started.

Yet, ideally, we do want to "link" our launcher to the spawned processes at the system level, such that the OS will make sure to terminate the subprocesses when we kill the parent. One way to do that is to have a shared socket between the launcher and its children (which will anyway be the case with the new Haskell node since we'll communicate through a pipe).

[piotr-iohk]

Well, it's not that we don't support SIGKILL, we do. But the semantic of SIGKILL doesn't allow us to do any clean-up after receiving it. So, if one kills the launcher, one doesn't kill the sub-processes the launcher has started.

Well, not very fortunate selection of words on my side but that's what I actually meant by saying don't support ^ ;) i.e. that we don't clean up after kill -9 as of now. So if we wan't to go for this shared socket now (or very soon) to support it - that's cool :). If not at this point (or not in the near future), that's also OK, but then it would be worth to state it somewhere as a known limitation. That's what I meant. :)

[pppsss40]

lgtm 👍

[piotr-iohk]

lgtm 👍