Problem with initial dispatcher via script - Erlang

Question

I made an OTP compatible application where I have gen_server and a supervisor. I also have a script to run them.

My script contains something like this. erl -pa module_name / ebin -name abc @hostname -setcookie test -s module_sup start_link ()

This does not start the dispatcher. But when I do module_sup: start_link () inside the shell, it works.

Also, when I do erl -pa computer_name / ebin -name abc @hostname -setcookie test -s module_srv start_link () that is, a server without a supervisor, the server starts.

So what am I doing wrong here. Are we allowed to run the dispatcher this way.

Any help would be greatly appreciated.

Thanx, Wilson

Answer 1

supervisor:start_link/2 creates a link to the calling process. when this calling process ends, the supervisor is removed with it.

erl -s module_sup start_link starts the supervisor, but it is killed because your start function starts inside its own process, which dies after the function finishes.

you can observe similar behavior with spawn(module_sup, start_link, []). when the supervisor starts and kills immediately. when you manually start the supervisor, the calling process is a wrapper. when the shell comes out, it will kill the supervisor.

typically, the top-level supervisor is designed to be run by the application.

Answer 2

This is very similar to How to run applications using the command line as a daemon? In short, you cannot use -s to start the supervisor unless you use unlink/1 , which is a full skim. Your time is better spent learning how to pack your code as application . I would recommend doing this with rebar .

Answer 3

It is important to note that a process only dies if the associated process ends for a reason other than “normal,” which means that a process that simply ends execution does not kill the processes associated with it. (source http://www.erlang.org/doc/reference_manual/processes.html#id204170 ) I think this is an important aspect of Erlang that should not be misinterpreted.

The following source code shows this:

 1> spawn( 1> fun() -> 1> io:format("outer ~p~n", [self()]), 1> spawn_link( 1> fun () -> 1> io:format("inner ~p~n", [self()]), 1> receive 1> Msg -> io:format("received ~p~n", [Msg]) 1> end 1> end) 1> end). outer <0.37.0> <0.37.0> inner <0.38.0> 2> is_process_alive(pid(0,37,0)). false 3> pid(0,38,0) ! test. received test test 4> 

You can see that the caller <0.37.0> is not working, but the process <0.38.0> is still present, waiting for the message.

In any case, the supervisor will not end when the caller ends, as the supervisor outputs the output signals. Of course, if it is not programmed for this. But I studied the source code and could not find it, but, alas, my analysis may have been too superficial.

Are you lucky with this? I will try to run some tests and see if I can understand what is going on.