Automatically starting applications in the correct order

You might be interested in Included Applications — Erlang System Documentation v29.0.2.

@idi527 - Thanks for the link!

As far as I can tell, the same challenge exists in Erlang as well:

Which applications to include is defined by the included_applications key in the .app file […]

When starting a primary application with included applications, the primary application is started the normal way, that is:

• The application controller creates an application master for the application.
• The application master calls Module:start(normal, StartArgs) to start the top supervisor.

Then, for the primary application and each included application in top-down, left-to-right order, the application master calls Module:start_phase(Phase, Type, PhaseArgs) for each phase defined for the primary application, in that order.

That is, the programmer is responsible for starting the applications in the correct order, by placing them in the correct order in the .app-file (under the included_applications key-key).

Perhaps this could be automated somehow by Elixir?

AFAIK the sasl is no longer an issue in OTP 21, since the logs are now produced by the erlang’s new :logger that is always started. sasl is now only what it was always supposed to be - just tooling for releases.

Each library we use in elixir and erlang is itself an app, so the app files can be written by the library author.

Thanks for the info! That’s good to know.

Are you aware of any other cases where the order in which the applications are included is significant, or was this just an odd exception case when using sasl in combination with logger?

@leifericf I’m running into a similar problem trying to send vmstats information to statsd via statix. I need to ensure that statix has connected to the statsd server before the vmstats application has started. The solution I came up with was to set the vmstats dependency to runtime: false and manually start it in my main application.

  defp deps do
    [
      # ...
      {:vmstats, "~> 2.3.0", runtime: false}
    ]
  end

  def start(_type, _args) do
    :ok = Strategies.Statix.connect()
    Application.start(:vmstats)

    Supervisor.start_link([], strategy: :one_for_one, name: MyApp.Supervisor)
  end

It would be fantastic if there was some way to specify the order in mix.exs without clobbering all applications by adding the applications key to def applications

I thought I had misunderstood something and made a fool of myself by posting this thread, so I’m glad to hear that somebody else might be having a related issue to vindicate me

I’m too much of a newbie to be able to provide advice for your specific situation, @rupurt, but I’m sure one of our forum friends of greater clout will swing by and knock it out the the park.

The problem with this approach is that the application is not included in the application list, even though it’s required at runtime. This means you can’t build a proper OTP release with distillery (I’m presuming you’re not doing it now, but might want to do in the future). Any other tool which relies on the application list will also not work properly.

Instead of using runtime: false, you could instead add the vmstats application to the included_applications list:

# mix exs
# ...
def application do
  [
    included_applications: [:vmstats],
    # ...
  ]
end

And then somewhere in the supervision tree include %{id: :vmstats, start: {:vmstats, :start, [:normal, []]}} as a child. This will work properly with distillery, since application will be included in the release, but it won’t be started when the release is booted. Instead, the app is started in your own supervision tree.

Alternatively you could use vmstats normally (i.e. drop included_applications and runtime: false). In your app startup callback you could invoke something like Application.put_env(your_app, :statix_connected?, true) immediately after invoking Statix.connect, and then in your sink callback function push the data only if Application.get_env(your_app, :statix_connected?) == true.

@sasajuric thanks for the detailed insight. You’re correct, I’m not deploying my app yet but did plan on using distillery for an OTP release so this has saved me a wall of head bashing in the future

Both approaches sound interesting and I can actually see me needing better error handling in the sink for when the statsd server is down etc… so I’ll probably go with that approach.

Cheers!