[erlang-questions] managing OS processes

[Tim Watson]

On 28 May 2012, at 15:13, Daniel Goertzen <daniel.goertzen@REDACTED> wrote:

> There is at least one portable C++ process management library out
> there that could be leveraged...
> 
> http://www.highscore.de/boost/process/process/introduction.html
> 
> ... and nifpp might be a good way to talk to it
> (https://github.com/goertzenator/nifpp)
> 
> 

What I'd really like is native processes, one per externally managed pid, wrapped around a native sub process management api for each supported platform. Monitoring becomes simple that way, as once the native process dies you put the exit code into the 'EXIT' message unless it is zero. Signal handling should be do-able too and I/O will be more erlang-ish.

> This might be a quick and dirty way to get it done, but this probably
> not what you want for something that is shooting for inclusion into
> OTP.  The library source should at least provide some good
> implementation guidance.
> 
> Dan.
> 
> 
> On Sat, May 26, 2012 at 5:00 PM, Anthony Molinaro
> <anthonym@REDACTED> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions