Erlang, process_flag trap_exit kills my gen_server from the CLI

Question

I have this gen_server that I am working with:

-module(user_info_provider).
-export([start_link/0, stop/0]).
-export([init/1, terminate/2, handle_info/2, handle_call/3, handle_cast/2,
 code_change/3]).
-export([request_user_info/2]).

-behaviour(gen_server).

start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

stop() ->
    gen_server:cast(?MODULE, stop).

request_user_info(From,UserId) ->
    gen_server:cast(?MODULE, {request_user_info, From, UserId}).
%% Callback Functions
init(_) ->
    process_flag(trap_exit, true),
    io:format("I am ~w ~n", [self()]),
    {ok, null}.
%% @doc terminate
terminate(Reason, _LoopData) ->
    io:format("Terminating by ~w~n",[Reason]),
    {ok, null}.
handle_cast({request_user_info,From,UserId}, LoopData) ->
    {noreply, LoopData};
handle_cast(stop, LoopData) ->
    {stop, normal, LoopData}.
handle_info(_Info, State) ->
    {ok, State}.
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.
handle_call(_,_From,LoopData) ->
    {ok,ok,LoopData}.

The problem is, as I show next, if I execute it from the cli like erl -pa ebin/ -s user_info_provider start_link it dies straight away, but then I can spawn it from the console and it works.

erl -pa ebin -s user_info_provider start_link
Erlang R14B02 (erts-5.8.3) [source] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false]

I am <0.32.0> 
Terminating by normal
Eshell V5.8.3  (abort with ^G)
1> user_info_provider:start_link().
I am <0.35.0> 
{ok,<0.35.0>}

This doesn't happen if I don't set process_flag(trap_exit, true) or I don't launch it directly from the console with -s module function.
I launch it like that because the real gen_server is way more complex and I am testing it standalone from a Makefile call.
Any ideas?

Answer 1

The solution is the one suggested by W55tKQbuRu28Q4xv or by not using start_link, only start. Here is what happens:

The -s parameter is handled by init. Roughly, init will spawn a new process which it then uses to initialize and run all -s parameters in. Afterwards this spawned process will exit.

Since the init-process exits, and you trap exits, your process receives a message {'EXIT', P, Reason} where P is the pid() of the spawned-by-init process. This message is handled by the gen_server portion of your process. Normally such a message would be forwarded to your handle_info/2 callback (which has the wrong return value in your code btw, should be noreply). But in this case, it will not be forwarded. The reason is that a gen_server contains a concept of its parent process. It notes which process spawned it, by means of the process dictionary and a value '$ancestors' put there by proc_lib. Now if the exit message arrives from the parent, then the terminate callback is immediately called and the process is terminated. Such a message will not be forwarded to you. This is what you see.

The solution, the pretty solution, is to create a small application, a supervisor, and put your process under that supervisor. Then call application:start(your_app) from -s. The reason this works is because the application controller runs separately. The even better solution is to build a release which will automatically start your application. A release is your application + its dependencies bundled together with an ERTS runtime. Such a release lives completely by its own and can be copied to the target host and run. No Erlang is thus needed on the target system as the release is self-containing.

Answer 2

Do minimal application with supervisor (rebar can generate skeleton of such application) and run it from cli with -s.