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

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Thu Sep 27 11:29:03 CEST 2012


I remember this was something I had going. Let me dig code:

----
#!/bin/sh

(cat && kill 0) | opentracker $*
----

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

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




More information about the erlang-questions mailing list