[erlang-questions] can a program launched with open_port({spawn, Cmd}, Options) remain running after the port closes?

[Serge Aleynikov]

Regarding the statement that "erlexec" hasn't been well maintained - if
you submit a bug report, I'll be happy to look into it, but other than
that I believe the project does well what it was designed to do - spawn
OS processes, pass them signals, chain them with links/monitors and link
them to Erlang PIDs, and kill them reliably by signals or custom
commands.  Hence I haven't had a need to evolve it beyond where it has
been as of right now.  My "wish list" included adding portability so
that it works on Windows as well as it does on Linux, but I never really
had a need for it, and if there's a volunteer for this task, I'd be glad
to accept patches.

Regards,

Serge


On 9/27/2012 3:11 PM, Tim Watson wrote:> On 27 Sep 2012, at 19:18,
freza@REDACTED wrote:
>> Haven't been following this thread closely, but it seems erlexec wasn't
>> mentioned yet:
>>
>> 	http://code.google.com/p/erlexec/
>
> Doesn't appear very well maintained. I might pick it apart and rewrite
it when native processes get released - it is a cool idea. Anyway, for
the time being it's not a great help as I'm writing a framework to help
set up and tear down clusters for distributed testing (based largely on
common test) so I want to minimise the number of dependencies as much as
possible. Besides, I'm more interested in working on the remote/ssh
runner+monitor next, rather than spending another age fiddling around
with the script runner.
>
> But yes, erlexec does look interesting and has been on my radar since
it popped up on this list a few months back, discussing the desire to do
proper signal handling (such as sending SIGTERM, SIGHUP, etc to the
external program) without resorting to os:cmd("kill -" ++ Code ++ " " ++
OsPid). Again, this is something that linked-in drivers *can* deal with
to a limited extent, and therefore I suspect that native processes will
make for a very nice foundation on which to build an alternative to
open_port/2.
>
> Also, IIRC there was a cool command line testing framework open
sourced in the last year which was announced on this list. I can't
remember what it was called, but it has a port driver that handles the
the external comms and so on - looked very nice, although that's not
what I'm trying to do/be as my focus is on getting things in a
consistent state and monitoring to make sure they stay that way through
the test run, then tearing down nicely before the next phase kicks off.
>
> Cheers,
> Tim
>