Cannot spawn an erlang supervisor from the shell.

Question

I've implemented a gen_server and supervisor: test_server and test_sup. I want to test them from the shell/CLI. I've written their start_link functions such that their names are registered locally.

I've found that I can spawn the test_server from the command line just fine, but a spawned test_sup does not allow me to interact with the server at all.

For example, I can spawn a test_server by executing:

1> spawn(test_server, start_link, []).
<0.39.0>
2> registered().
[...,test_server,...]

I can interact with the server, and everything appears fine.

However, if I try to do the same thing with test_sup, no new names/Pids are registered in my "CLI process" (using registered/0). My test_server appears to have been spawned, but I cannot interact with it (see Lukas Larsson's comment about SASL to see why this is true).

I'd assume I coded an error in my supervisor, but this method of starting my supervisor works perfectly fine:

1> {ok, Pid}= test_sup:start_link([]).
{ok, <0.39.0>}
2> unlink(Pid).
true
3> registered().
[...,test_server,test_sup,...]

Why is it that I can spawn a gen_server but not a supervisor?

---

Update

The code I'm using can be found in this post. I'm using echo_server and echo_sup, two very simple modules.

Given that code, this works:

spawn(echo_server, start_link, []).

and this does not:

spawn(echo_sup, start_link, []).

Answer 1

Whenever trying to figure these things out it is usually very helpful to switch on SASL.

application:start(sasl).

That way you will hopefully get to know why you supervisor is terminating.

Answer 2

This explanation was given by Bernard Duggan on the Erlang questions mailing list:

Linked processes don't automatically die when a process they are linked to exits with code 'normal'. That's why [echo_server] doesn't exit when the spawning process exits. So why does the supervisor die? The internals of the supervisor module are in fact themselves implemented as a gen_server, but with process_flag(trap_exit, true) set. The result of this is that when the parent process dies, terminate() gets called (which doesn't happen when trap_exit is disabled) and the supervisor shuts down. It makes sense in the context of a supervisor, since a supervisor is spawned by its parent in a supervision tree - if it didn't die whenever its parent shutdown, whatever the reason, you'd have dangling "branches" of the tree.