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

[Erik Søe Sørensen]

2012/9/27 Jesper Louis Andersen <jesper.louis.andersen@REDACTED>

> I remember this was something I had going. Let me dig code:
>
> ----
> #!/bin/sh
>
> (cat && kill 0) | opentracker $*
>
Nice incantation. I was just about to suggest using a wrapper program, but
I probably wouldn't have thought of that variation.


> ----
>
> So the trick is that the … && kill 0 part sends a kill signal to all
> processes in the current process group. This lets you stop another process
> since cat(1) understands what happens when stdin is closed and handles it
> accordingly.
>
> I've only used it in tests though so it may need work for real programs
>
Such as replacing "&&" with ";" ? :-)
Just in case someone came along and killed the cat. (Can't at the moment
imagine other scenarios where cat would exit with non-zero return values,
but they probably exist.)

Also, replace $* with "$@" (including the quotes), for proper handling of
parameters with spaces in them and such.

/Erik



>
> Jesper Louis Andersen
>   Erlang Solutions Ltd., Copenhagen
>
>
>
> On Sep 27, 2012, at 4:20 AM, Erik Søe Sørensen <eriksoe@REDACTED> wrote:
>
> > It is the responsibility of the port program to shut down when stdin
> reaches EOF.
> > This behaviour/expectation confused me too at some point, but it
> probably has its merits: not all software is designed for "let it crash",
> so simply killing the port program might be too crude in some circumstances.
> >
> > Den 26/09/2012 23.55 skrev "Tim Watson" <watson.timothy@REDACTED>:
> > I'm seeing this happen, and it's most confusing. The program is not
> launched using nohup/setsid or anything to send it to the background. The
> arguments passed to open_port/2 are thus:
> >
> > [{args, Args}, {env, Env}, exit_status, hide, stderr_to_stdout,
> use_stdio, {line, 16384}]
> >
> > The script that is being run essentially does this:
> >
> > # fiddle around with some environment variables, then
> > exec erl \
> >     -pa ${EBIN_ROOT} \
> >     ${START_INSTRUCTION} \
> >     -sname ${NODENAME} \
> >     -boot start_sasl \
> >     ${CONFIG_ARG} \
> >     +W w \
> >     ${SERVER_ERL_ARGS} \
> >     ${LISTEN_ARG} \
> >     "$@"
> >
> >
> > After some tests are run, the port is closed (using close_port). The
> connected process for the port is a gen_server, so it's *possible* that
> this exits without cleanly shutting down, but I'm under the impression
> (from experimentation) that if the connected process dies, the port is
> closed anyway. Nevertheless, I'm seeing *stuck nodes* that survive the test
> run and are locked up because some code on the node (which should be dead
> after the port goes) is stuck in an io:format/2 call which will never
> return because stdout is not responding - hardly surprising under the
> circumstances.
> >
> > Can someone explain to me what's going on here? Is this an issue with
> the exec call, and if so what is the problem with it? I've got a minimal
> example using exec that doesn't behave like this, so I'm a bit bemused.
> What's really confusing is that the process the port is used to open should
> presumably be closed regardless of what some sub-process is doing, and I
> thought that exec returned the stdout of the subprocess anyway!?
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120927/a9b8d7df/attachment.htm>