Any incoming message while waiting for sync subprocess treated as error about erlexec

[saleyn]

This function was added by one of the contributors, and all side-effects may not have been fully tested.

The function is reporting that it doesn't recognize the 'test' message, which is correct. Though, it's questionable if in that case the waiting process needs to be crashed or handle it the way it does.

[0xNaN]

Hi, I'm dealing with what I think could be a strange behaviour (but I'm not really sure though!) and I think could be linked to this issue.
When running a process without linking to it and then killing it in a sync way, works without problems:

(3334@workstation)1> exec:run("sleep 100", []).
{ok,<0.105.0>,19393}
(3334@workstation)2> exec:run("kill 19393", [sync]).
{ok,[]}

But if the shell trap_exit and the first process is linked to it:

(3334@workstation)3> process_flag(trap_exit, true). 
false
(3334@workstation)4> exec:run_link("sleep 100", []).
{ok,<0.110.0>,19686}
(3334@workstation)5> exec:run("kill 19686", [sync]).
{error,[{reason,{'EXIT',<0.110.0>,{exit_status,15}}}]}
(3334@workstation)6> flush().
Shell got {'DOWN',#Ref<0.0.2.167>,process,<0.112.0>,normal}
ok
(3334@workstation)7> 

the kill process on 5> dies with an error that is the EXIT of the sleep process (that I expected to trap) while the shell traps a DOWN (which I think became from the iternal of 5>);

What I'm expecting is that 5> evaluates simply to {ok,[]} ( since kill exits with 0) and the shell traps the EXIT message.

I'm missing something?

EDIT
I've done a really simple test that partially solve this issue (if it will be confirmed): moving the monitor creation and the call wait_for_ospid_exit(OsPid, Ref, [], []); in a dedicated process.
For example, introducing two functions (wait and waiter) and turning the case on do_run to

    ...
    ...
    case {Mon, gen_server:call(?MODULE, Cmd2, 30000)} of
        {true, {ok, Pid, OsPid} = R} ->
            case Sync of
                true -> 
                    Parent = self(),
                    Waiter = spawn(fun() -> waiter(Parent, OsPid, Pid) end),
                    wait(Waiter, OsPid, Pid);
                _    -> R
            end;
        {_, R} ->
            R
    end.

wait(Waiter, OsPid, Pid) ->
    receive
        {stdout, OsPid, Data} ->
            Waiter ! {stdout, OsPid, Data},
            wait(Waiter, OsPid, Pid);
        {stderr, OsPid, Data} ->
            Waiter ! {stderr, OsPid, Data},
            wait(Waiter, OsPid, Pid);
        {Waiter, Ret} -> Ret
    end.

waiter(Parent, OsPid, Pid) ->
    Ref = monitor(process, Pid),
    Ret = wait_for_ospid_exit(OsPid, Ref, [], []),
    Parent ! {self(), Ret}.

wait(OsPid, Pid) ->
    Parent = self(),
    Waiter = spawn(fun() -> waiter(Parent, OsPid, Pid) end),
    receive
        {Waiter, Ret} -> Ret
    end.

Breaks some test but produce the following outcome:

Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V7.1  (abort with ^G)
1> application:start(erlexec).
ok
2> spawn(fun () -> io:format("~p~n", [exec:run("sleep 3 && echo done", [sync, stdout])]) end) ! test.
test
{ok,[{stdout,[<<"done\n">>]}]}
3> process_flag(trap_exit, true).
false
4> exec:run_link("sleep 100 && echo done", []).
{ok,<0.125.0>,4159}
5> exec:run("kill 4159", [sync]).
{ok,[]}
6> flush().
Shell got {'EXIT',<0.125.0>,{exit_status,15}}
ok
7> 

[saleyn]

Is it possible you are not running the latest version of erlexec?

Here's what I get when I execute your example on the master branch of the project:

(mta@nova)18> process_flag(trap_exit, true).                    
true
(mta@nova)19> f(P), {ok, _, P} = exec:run_link("sleep 100", []).
{ok,<0.6702.0>,27603}
(mta@nova)20> exec:run("kill " ++ integer_to_list(P), [sync]).  
{ok,[]}
(mta@nova)21> flush().
Shell got {'EXIT',<0.6702.0>,{exit_status,15}}
ok

[nwalker]

Issue already fixed in master by 95a9f21 / #58

[0xNaN]

yes I was using an old version I'm really sorry!
I was using erlexec through rebar3 simply using {deps, [erlexec]} (therefore using the latest version available on hex.pm I think).
Using this repo solves my issue! anyway thank you so much 😄