Reasons starting a supervised process, e.g. gen_server might fail

Chat / Discussions
, ,
1

When starting a process under supervision the supervisor is given a start function for the child.
This start function must return one of the following.

  • {:ok, pid}
  • {:ok, pid, term}
  • :ignore
  • {:error, reason}

https://erlang.org/doc/man/supervisor.html

I’m trying to find examples for all the reason you might have a process fail to start.

The reasons I have found so far are.

  1. Invalid configuration
    For example a database that takes a url as start argument but the string might not be a valid database url.
DB.start_link(url: "!I'm no url")

  1. Unavailable external service
    When starting a process if it cannot connect to a required resource then the pid fails to start. Again failing to connect to a database is an example of this.

  2. Process name is already taken
    Process can be started with Atom names, if the name is already taken the process would fail to start.

If you can think of any additions to this list I would greatly appreciate them. Examples would be even more awesome, thank you. :duck:

3 Likes
2

I’ve sometimes used ignore when I don’t want a subsystem to run, for example debugging code used in development.

2 Likes
3

We have something similar. A part of our app is exchangeable via configuration and using a behavior. Certain implementations require an additional supervision tree, while others do not.

In that scenario init is an optional callback, where we fallback on :ignore as a default if not implemented.

2 Likes
4

So the only thing missing from my original list was an ignore option.

With this feedback I am certainly up for trying some supervisor designs which do not allow a process to fail at startup. i.e. start -> {:ok, pid} becomes start -> pid

I think external service checking should not be done in the init callback of a Gen_* process.
And for now I think I have another approach to naming.