Editing Draft:Elixir/OS processes (section)

==== Reliable clean up ====
What I discovered is that the BEAM external process library assumes that its spawned processes will respond to standard input and output shutting down or so called end of file, for example what happens when <control>-d is typed into the shell.  This works very well for a subprocess like <code>bash</code> but has no effect on a program like <code>sleep</code> or <code>rsync</code>.

The hole created by this mismatch is interestingly solved by something shaped like the BEAM's supervisor itself.  I would expect the VM to spawn many processes as necessary, but I wouldn't expect the child process to outlive the VM, just because it happens to be insensitive to end of file.  Instead, I was hoping that the VM would try harder to kill these processes as the Port is closed, or if the VM halts.

In fact, letting a child process outlive the one that spawned it is unusual enough that the condition is called an "orphan process".  The POSIX standard recommends that when this happens the process should be adopted by the top-level system process "init" if it exists, but this is a "should have" and not a must.  The reason it can be undesirable to allow this to happen at all is that the orphan process becomes entirely responsible for itself, potentially running forever without any more intervention according to the purpose of the process.  Even the system init process tracks its children, and can restart them in response to service commands.  Init will know nothing about its adopted, orphan processes.

When I ran into this issue, I found the suggested workaround of writing a [https://hexdocs.pm/elixir/1.18.3/Port.html#module-zombie-operating-system-processes wrapper script] to track its child (the program originally intended to run), listen for the end of file from BEAM, and kill the external program.  How much simpler it would be if this workaround were already built into the Erlang Port module!

It's always a pleasure to ask questions in the BEAM communities, they have earned a reputation as being friendly and open.  The first big tip was to look at the third-party library [https://hexdocs.pm/erlexec/ erlexec], which demonstrates some best practices that might be backported into the language itself.  Everyone speaking on the problem has generally agreed that the fragile clean up of external processes is a bug, and supported the idea that one of the "terminate" signals should be sent to spawned programs.

Which signal to use is still an open issue, there's a softer version <code>HUP</code> which says "Goodbye!" and the program is free to interpret as it will, the mid-level <code>TERM</code> that I prefer because it makes the intention explicit but can still be blocked or handled gracefully if needed, and <code>KILL</code> which is bursting with destructive potential.  The world of unix signals is a wild and scary place, on which there's a refreshing diversity of opinion around the Internet.