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

Tim Watson watson.timothy@REDACTED
Wed Sep 26 23:54:55 CEST 2012


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120926/7fe37907/attachment.bin>


More information about the erlang-questions mailing list