saleyn / erlexec

Execute and control OS processes from Erlang/OTP
https://hexdocs.pm/erlexec/readme.html
Other
541 stars 141 forks source link

Exit code mismatch #50

Closed eproxus closed 9 years ago

eproxus commented 9 years ago

Running erlexec with monitor as an option, I receive {'DOWN', #Ref<0.0.0.3303>, process, <0.207.0>, {exit_status, 256}}, however running the command in the shell returns the error code 1.

The command is started with:

exec:run(["/path/to/command", "--id", "1", "--control", ":3333"], [monitor, {stdout, print}, {stderr, print}, {kill_timeout, 1}])

The output and message received is:

Got stderr from 66903: <<"time=\"2015-07-16T16:18:53+02:00\" level=fatal msg=\"Could not create controller: dial tcp 127.0.0.1:23000: connection refused\" \n">>
{'DOWN', #Ref<0.0.0.3303>, process, <0.207.0>, {exit_status, 256}}

However, running the command in the shell shows the error code is actually 1:

$ /path/to/command --id 1 --control :3333
FATA[0000] Could not create controller: dial tcp :3333: connection refused
$ echo $?
1
saleyn commented 9 years ago

You need to use the exec:status/1 call to interpret the exit code reported by exec, which could be either a signal or status, depending on the termination cause:

2> exec:status(256).
{status,1}
3> exec:status(1).
{signal,sighup,false}
eproxus commented 9 years ago

Excuse my lack of knowledge, on the subject, but why? :smile: What's the difference between status and status in these contexts?

saleyn commented 9 years ago

The exit code returned by Linux and other OS's that support signals contains information on how the process was terminated (normally or by signal), so the value returned in {exit_status, N} needs to be interpreted by the exec:status/1 call to get the "real" exit status.

eproxus commented 9 years ago

I see, thanks!