Application Crashing with Runtime Error in Elixir 1.17.2

neel-desh

Start Call: :disk_log_sup.start_link()
12:52:11.524 [info] Child :disk_log_server of Supervisor :kernel_safe_sup started
Pid: #PID<0.3050.0>
Start Call: :disk_log_server.start_link()
{exit,terminating,[{application_controller,call,2,[{file,"application_controller.erl"},{line,511}]},{application,enqueue_or_start,6,[{file,"application.erl"},{line,380}]},{application,ensure_all_started,3,[{file,"application.erl"},{line,359}]},{elixir,start_cli,0,[{file,"src/elixir.erl"},{line,195}]},{init,start_it,1,[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}
Runtime terminating during boot (terminating)

12:52:11.600 [info] Child Tzdata.EtsHolder of Supervisor #PID<0.3047.0> (Supervisor.Default) started
Pid: #PID<0.3048.0>
Start Call: Tzdata.EtsHolder.start_link([])
Crash dump is being written to: erl_crash.dump...done

Facing this issue on

ELIXIR_VERSION=1.17.2
OTP_VERSION=27.0.1
ALPINE_VERSION=3.20.2

My application file

defmodule Butcher.Application do
  @moduledoc false

  use Application

  @impl true
  def start(_type, _args) do
    opts = [strategy: :one_for_one, name: Butcher.Supervisor]

    children = [
      ButcherWeb.Telemetry,
      {Phoenix.PubSub, name: Butcher.PubSub},
      ButcherWeb.Endpoint,
      Butcher.Repo,
    ]

    Supervisor.start_link(children, opts)
  end

  @impl true
  def config_change(changed, _new, removed) do
    ButcherWeb.Endpoint.config_change(changed, removed)
    :ok
  end
end

My Runtime configs

  config :butcher, ButcherWeb.Endpoint,
    server: true,
    url: [host: host, port: https_port, scheme: "https"],
    http: [
      port: port,
      transport_options: [socket_opts: [:inet6]]
    ],
    https: [
      port: https_port,
      cipher_suite: :strong,
      keyfile: key_path,
      certfile: cert_path,
      cacertfile: cacert_path,
      transport_options: [socket_opts: [:inet6]]
    ],
    secret_key_base: secret_key_base

I was able to pinpoint that commenting endpoint in application resulted into starting of application.

Not sure what I’m missing

6 comments

/phoenix #deployment #troubleshooting

1 732 6

2024-09-12 17:37:18 UTC

Showing Posts 1 to 6

Show Best Posts
Show All (oldest first)
Show All (newest first)

mmmrrr

Hey @neel-desh! First of all: great to have you here

I think your error might be a problem with you erlang installation. There is an older thread where people were complaining about a similar behavior under Mac OS: Fresh install + new project + mix test causes crash (1.14.3) - #12 by kushalj

Is this an issue you only see when running in production? Or do you also see this problem in development?

If the former: have you bundled erlang along with your release, or are you by chance using your system binaries?

Post #1

neel-desh

Hey mmmrrr, thanks for taking out time to reply.

Okay, so the issue was in the docker file that phoenix generated,


WORKDIR "/app"
RUN chown nobody /app

# set runner ENV
ENV MIX_ENV="prod"

# Only copy the final release from the build stage
COPY --from=builder --chown=nobody:root /app/_build/${MIX_ENV}/rel/butcher ./

USER nobody

The app did not had the permission to listen on port 80 and 443 since privilege ports! and it was resulting in the above crash

Removing

RUN chown nobody /app

USER nobody

and Modifying this line worked for us

COPY --from=builder /app/_build/${MIX_ENV}/rel/butcher ./

Post #2

mmmrrr

Hey @neel-desh.
Glad to hear that you were able to pin down the problem yourself!

Just a heads up: you’re potentially opening up a security issue by running the application as root in the container! That’s why this configuration is there in the first place.

Imho the better way would be to not make the app listen on a non priviledged port and then use a reverse proxy (like nginx, or caddy, or traefik, …) to provide the TLS termination, static file routing, or whatever.

While this is not strictly necessary, and sometimes even detrimental if you have a specific setup in mind, I am always suspicious when someone runs software as root

Good luck with your software!

Post #3

ryanzidago

I’m encountering the same error while deploying on Fly.io; any idea why running the app as root fixes the issue? Why does this issue happen in the first place?

Post #4

neel-desh

In my particular case, I was using a privileged port 80

In Linux, a privileged port is a port in the range 1-1023 . By default, privileged ports can’t be bound to non-root processes.

Since a non-root user couldn’t access these ports, the application failed to start, causing a crash. When you run as a root user, you have permission to access the port.

can you share more details, on the config or dockerfile in your case??

Post #5

ryanzidago

Hey thanks; I managed to solve the issue. In my case it was due to the nobody user not having the required privileges for writing to the Bumblebee / hf caches.

I’ve managed to solve it