Distillery fails at startup

Phoenix Forum Questions / Help
,
1

I build now with distillery, but unfortunately I haven’t got it working yet:

Application my_app exited: exited in: MyApp.start(:normal, [])
    ** (EXIT) exited in: GenServer.call(Mix.State, {:get, {Map, :get, [:env, :dev]}}, 5000)
        ** (EXIT) no process: the process is not alive or there's no process currently associated with
 the given name, possibly because its application isn't started
Kernel pid terminated (application_controller) ({application_start_failure,my_app,{bad_return,
{{'Elixir.MyApp',start,[normal,[]]},{'EXIT',{noproc,{'Elixir.GenServer',call,['Elixir.
{"Kernel pid terminated",application_controller,"{application_start_failuremy_app,{bad_return,
{{'Elixir.MyApp',start,[normal,[]]},{'EXIT',{noproc,{'Elixir.GenServer',call,['Elixir.Mix.State',{get,
{'Elixir.Map',get,[env,dev]}},5000]}}}}}}"}

I wonder why it wants to access dev stuff even though I’m building with prod and have set MIX_ENV=prod. I build my release with MIX_ENV=prod mix release --env=prod and execute my application with the following commands:

/phoenix/bin/my_app migrate
trap 'exit' INT; exec /phoenix/bin/my_app foreground

Funnily, the migration step works like a charm, just the second crashes.

Thats my distillery config:

~w(rel plugins *.exs)
|> Path.join()
|> Path.wildcard()
|> Enum.map(&Code.eval_file(&1))

use Mix.Releases.Config,
    # This sets the default release built by `mix release`
    default_release: :default,
    # This sets the default environment used by `mix release`
    default_environment: Mix.env()

environment :dev do
  set dev_mode: true
  set include_erts: false
  set cookie: :"sfds"
end

environment :prod do
  set config_providers: [
    {Mix.Releases.Config.Providers.Elixir, ["${RELEASE_ROOT_DIR}/etc/config.exs"]}
  ]
  set overlays: [
    {:copy, "rel/config/config.exs", "etc/config.exs"}
  ]
  set include_erts: true
  set include_src: false
  set cookie: :"sdfsfd"
  set vm_args: "rel/vm.args"
end


release :sports_connected do
  set version: current_version(:sports_connected)
  set applications: [
    :runtime_tools
  ]
  set commands: [
    migrate: "rel/commands/migrate.sh"
  ]
end
2

I guess it’s the same issue as here: Mix.env() in production no longer produces nil, but crashes Mix.State genserver

3

I was able to fix the above error but I’m now stuck with

Application sports_connected exited: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: MyApp.Endpoint
    ** (EXIT) an exception was raised:
        ** (UndefinedFunctionError) function Plug.Cowboy.child_spec/1 is undefined (module Plug.Cowboy is not available)
            Plug.Cowboy.child_spec([scheme: :http, plug: {SportsConnected.Endpoint, []}, options: [dispatch: [_: [{:_, Phoenix.Endpoint.Cowboy2Handler, {SportsConnected.Endpoint, []}}]], port: 4000, otp_app: :my_app]])
            (phoenix) lib/phoenix/endpoint/cowboy2_adapter.ex:44: Phoenix.Endpoint.Cowboy2Adapter.child_spec/3
            (phoenix) lib/phoenix/endpoint/supervisor.ex:106: anonymous fn/6 in Phoenix.Endpoint.Supervisor.server_children/4
            (elixir) lib/enum.ex:1940: Enum."-reduce/3-lists^foldl/2-0-"/3
            (phoenix) lib/phoenix/endpoint/supervisor.ex:97: Phoenix.Endpoint.Supervisor.server_children/4
            (phoenix) lib/phoenix/endpoint/supervisor.ex:57: Phoenix.Endpoint.Supervisor.init/1
            (stdlib) supervisor.erl:295: :supervisor.init/1
            (stdlib) gen_server.erl:374: :gen_server.init_it/2
4

Because plug is not part of your application list.

Have you considered relying on inference rather than to specify each manually?

1 Like
5

Oh, I weren’t aware of that.

Did you mean that change?

release :my_app do
  set version: current_version(:my_app)
  set applications: elem(List.last(MyApp.Mixfile.application()), 1)
  set commands: [
    migrate: "rel/commands/migrate.sh"
  ]
end

Unfortunately, it still fails :confused:

6

I mean by leaving of setting the :applications key and just rely on what mix has inferred.

7

Here’s a supplemental blog post about moving from using :applications to :extra_applications: https://www.amberbit.com/blog/2017/9/22/elixir-applications-vs-extra_applications-guide/

It doesn’t directly talk about releases but I believe the concept is the same.

2 Likes