[erlang-questions] managing OS processes

Zabrane Mickael zabrane3@REDACTED
Sun May 27 00:48:22 CEST 2012


Quick look to "erlexec" code shows that's only support Linux for now (with dependency on libpcap).
Any revival work should extend "erlexec" to all other OSes when Erlang is expected to run (ex. Windows, OSX, FreeBSD ...) and try to minimize external dependencies.

+1 

I would be willing to help for a complete rewrite of "erlexec" (as Tim, I'm more C than a C++ guy).

Regards,
Zabrane

On May 27, 2012, at 12:00 AM, Anthony Molinaro wrote:

> I've found a need for this sort of thing as well.  +1 for getting something
> into OTP itself.   I'm sure the real issue will be with Windows, although
> I believe there was some code in couchdb for doing some control of windows
> processes, and maybe erlexec already supports Windows?  Anyway, I can't
> say I'd do much other than testing, but just wanted to voice my support.
> 
> -Anthony
> 
> On Sat, May 26, 2012 at 09:52:32PM +0100, Tim Watson wrote:
>> I'm also working on very similar requirements in
>> https://github.com/nebularis/systest/blob/master/src/systest_cli.erl
>> and like you two, I have to rely on a combination of open_port with
>> its constituent events and os:cmd/1 in order to SIGHUP/SIGKILL which
>> feels rather 'hackish' to me. I've also noticed that it makes consumer
>> code rather timing dependent, which is frustrating.
>> 
>> I would be willing to participate in either
>> 
>> (a) improving the built in port functionality or
>> (b) working on erlexec
>> 
>> Although C I'm fairly comfortable with, but C++ (which erlexec appears
>> to be written in) isn't really my bag. I do have to ask though, is
>> erlexec in need of much additional work? I also have 'client' modules
>> for the OTP slave and ssh modules and don't want to invest a mountain
>> of time in replacing open_port, but a little TLC to bring erlexec up
>> to scratch would be time well spent if it would give a more consistent
>> interface. In particular I have some issues with open_port based code
>> with now such as
>> 
>> 1. cli clients my code launches can be 'detached' (usually erlang
>> nodes run with -detached or scripts that launch erlang nodes using `sh
>> -C` or setsid/nohup and the like), which makes the port handling code
>> both complex and messy.
>> 2. some client code I'm testing will execute another (different)
>> script/command to shut down the node and the listening port doesn't
>> always get the exit status properly
>> 3. signal handling is a mess
>> 
>> So erlexec does sound promising, but IMO it would be *better* if the
>> built in open_port functionality could be extending to deal with these
>> situations properly.
>> 
>> Cheers,
>> Tim
>> 
>> On 26 May 2012 13:12, Gleb Peregud <gleber.p@REDACTED> wrote:
>>> On Sat, May 26, 2012 at 11:06 AM, Benoit Chesneau <bchesneau@REDACTED> wrote:
>>>> I'm trying to find a way to manage some os processes launched from
>>>> Erlang. For example I need to relaunch them when the external process
>>>> die for an unknown reason or send an HUP signal or just stop the
>>>> external process.
>>> 
>>> Hello Benoit
>>> 
>>> Looks like there are two of us, who needs a better mechanism to manage
>>> OS processes from Erlang. I need it for a CI server which I'm working
>>> on, so my requirements are not as high as yours, but still os:cmd
>>> doesn't work for me and ports are missing one feature which I need.
>>> 
>>> Maybe we could reanimate erlexec together?
>>> 
>>> Cheers,
>>> Gleb
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 
> -- 
> ------------------------------------------------------------------------
> Anthony Molinaro                           <anthonym@REDACTED>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions






More information about the erlang-questions mailing list