[erlang-questions] Port process exits with status einval while external program still runs

Michael Truog mjtruog@REDACTED
Sat May 27 21:28:26 CEST 2017


On 05/27/2017 12:06 PM, Khitai Pang wrote:
> On 2017/5/28 01:45, Michael Truog wrote:
>> On 05/27/2017 09:21 AM, Khitai Pang wrote:
>>> On 2017/5/28 00:06, Michael Truog wrote:
>>>>
>>>>  On 2017/5/27 23:31, Khitai Pang wrote:
>>>>>> I have observed a situation where the port process exits with reason
>>>>>> 'einval' but the external program still runs.  The connected process of
>>>>>> the port receives {EXIT,#Port<0.3069817>,einval}. What makes a port
>>>>>> process exit with 'einval' while the external program still runs?
>>>>
>>>> Normally that is due to the port source code
>>>
>>> Do you mean the source code of the external program?
>>
>> Yes
>>
>>>
>>>> not handling a HUP on the output file descriptor,from poll (POLLHUP) or the equivalent using a different function.
>>>
>>> Could you be more specific about this situation?  In what occasions will this happen?
>>>
>>> My external program is a python script that uses erlport <https://pypi.python.org/pypi/erlport> to communicate with erlang.
>>
>> erlport should be getting EPIPE in the source code https://github.com/hdima/erlport/blob/master/priv/python2/erlport/erlproto.py#L106-L110 .  However, that depends on the write function getting called to discover the Erlang VM disappeared.
>
> Thank you for your explanation, but I don't really understand, if the cause is that the Erlang VM certainly disappeared, how come the connected process got the {EXIT,#Port<0....>,einval} message?
That message is the Erlang message inside the Erlang VM related to the Erlang port type used for the pipes that were used for the erlport executable.  So, that means the Erlang port type died with a posix einval error, but that doesn't mean that the erlport executable is aware of a problem.  It is possible the error is only seen by the Erlang VM if the erlport has no reason to call the write function, mentioned above.
>
> Anyway, what to do to avoid this issue?
Not sure, it may require changing erlport or taking a different approach.  To avoid the problem, you could attempt to always make the erlport executable exit by executing "sys.exit(0)" or something similar, but that isn't dependable when you are unable to send erlport something to exit (i.e., if a sudden error makes the Erlang port type unusable in the Erlang VM, as appears to have happened here).

Best Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170527/7cc08cb1/attachment.htm>


More information about the erlang-questions mailing list