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

[Tim Watson]

Hey Serge,

I wasn't insinuating that erlexec isn't fit for purpose, just that it doesn't seem to be under active development. From the sounds of things, that's because it's relatively stable, which is cool. Thanks for piping up and pointing that out - I will look at it for some other projects I've got brewing.

Cheers
Tim

On 27 Sep 2012, at 20:47, Serge Aleynikov <serge@REDACTED> wrote:

> 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
>>