Problem starting Phoenix app - Application ssl exited

Phoenix Forum Questions / Help
1

I have a Phoenix app that I migrated from an Intel Mac to an M1 Mac that no longer works, despite that fact that both Elixir and Erlang seem to be working fine:

% elixir -v
Erlang/OTP 26 [erts-14.0.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns] [dtrace]

Elixir 1.15.2 (compiled with Erlang/OTP 26)

% erl -v
Erlang/OTP 26 [erts-14.0.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns] [dtrace]

Eshell V14.0.2 (press Ctrl+G to abort, type help(). for help)
1>

Here’s what happens when I try to start my app with iex:

% iex -S mix phx.server  

11:41:49.298 [notice] Application ssl exited: exited in: :ssl_app.start(:normal, [])
    ** (EXIT) an exception was raised:
        ** (ArgumentError) could not call Module.put_attribute/3 because the module Myapp.MixProject is already compiled
            (elixir 1.15.2) lib/module.ex:2310: Module.assert_not_readonly!/2
            (elixir 1.15.2) lib/module.ex:2007: Module.__put_attribute__/5
            (ssl 11.0.2) ssl_app.erl:35: :ssl_app.stop/1
            (kernel 9.0.2) application_master.erl:293: :application_master.start_it_old/4

11:41:49.306 [notice] Application public_key exited: :stopped

11:41:49.306 [notice] Application asn1 exited: :stopped

11:41:49.307 [notice] Application crypto exited: :stopped
Could not start Hex. Try fetching a new version with "mix local.hex" or uninstalling it with "mix archive.uninstall hex.ez"
** (MatchError) no match of right hand side value: {:error, {:ssl, {:bad_return, {{:ssl_app, :start, [:normal, []]}, {:EXIT, {%ArgumentError{message: "could not call Module.put_attribute/3 because the module Myapp.MixProject is already compiled"}, [{Module, :assert_not_readonly!, 2, [file: ~c"lib/module.ex", line: 2310]}, {Module, :__put_attribute__, 5, [file: ~c"lib/module.ex", line: 2007]}, {:ssl_app, :stop, 1, [file: ~c"ssl_app.erl", line: 35]}, {:application_master, :start_it_old, 4, [file: ~c"application_master.erl", line: 293]}]}}}}}}
    (hex 2.0.6) lib/hex.ex:5: Hex.start/0
    (mix 1.15.2) lib/mix/hex.ex:60: Mix.Hex.start/0
    (mix 1.15.2) lib/mix/dep/loader.ex:189: Mix.Dep.Loader.with_scm_and_app/5
    (mix 1.15.2) lib/mix/dep/loader.ex:141: Mix.Dep.Loader.to_dep/4
    (elixir 1.15.2) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (mix 1.15.2) lib/mix/dep/loader.ex:364: Mix.Dep.Loader.mix_children/3
    (mix 1.15.2) lib/mix/dep/loader.ex:18: Mix.Dep.Loader.children/1
    (mix 1.15.2) lib/mix/dep/converger.ex:105: Mix.Dep.Converger.all/4

I get the same error if I run mix local.hex as it suggests. When I try the uninstall suggestion I get the following:

% mix archive.uninstall hex.ez
zsh: illegal hardware instruction  mix archive.uninstall hex.ez

Any ideas? It sounds like some thing is wrong with the migrated application but I can’t work out what.

Any ideas?

2

I would try rolling back Elixir versions and Erlang Versions slightly. I’ve found sometimes the latest versions don’t work with Phoenix.

I am currently using:

elixir 1.13.2-otp-24
erlang 25.0.2

Best of luck.

1 Like
3

Thanks Hari, I appreciate the reply. I’ll try that and report back here.

4

I went to downgrade my Elixir/Erlang but this actually turns out to be not straightforward, at least not on macOS. The recommended way to install Elixir on macOS is with Brew or MacPorts, but neither supports anything except the latest version.

It seems odd that the default install process for Phoenix currently fails for me on an M2 Mac if you follow the conventional path:

brew install elixir …OK, installs Erlang also
mix local.hex …OK
mix archive.install hex phx_new …segfault:

Resolving Hex dependencies...
Resolution completed in 0.015s
New:
  phx_new 1.7.6
* Getting phx_new (Hex package)
All dependencies are up to date
Compiling 11 files (.ex)
zsh: segmentation fault  mix archive.install hex phx_new
5

segfault makes me wonder whether it’s someone trying to run amd64-compiled Erlang. Not sure if that’s verifiable, though.

6

Actually I am using asdf on m1 and it works flawlessly, so there is no reason to use brew for managing your erlang/elixir version.

1 Like
7

Something about Rosetta vs. native ARM could be your problem.

8

But if it’s a Rosetta vs. native ARM issue surely Elixir and Erlang wouldn’t work at all, right? The REPLs for both run fine.

9

Yes but I don’t remember well the entire combo of things that have to be right f.ex. I think homebrew has to be the ARM version as well.

1 Like
10

Hmm yes, running brew info says the following (amongst lots of other output):

Rosetta 2: true
11

Use asdf version manager. Maybe even go so far as to uninstall elixir and erlang that were installed by brew.

I tend to lock down my language versions to a folder using for example:

asdf local elixir 1.13.2-otp-24
asdf local erlang 25.0.2

this will generate a .tool-versions file in the folder and directs asdf to use the versions specified for all child directories.

1 Like
12

asdf is great, I started using rtx though – it’s faster and is compatible with the .tool-versions files that asdf produces.

13

Does rtx offer any advantages over asdf, especially when it comes to nix and nixos? I’ve been wanting to check out nix for a little bit now.

14

I observed slightly reduced startup time of e.g. iex with it. Plus, all of its sub-commands (excluding those that hit the network e.g. list-all) are instant, whereas asdf is pretty laggy.

Maybe #2 is not the biggest selling point but these annoyances add up, at least for me. rtx completely eliminated them.

15

I think it has something about not using shims by default, however I have no idea what are those and what their problem is.

16

TL;DR shims are like wrappers that are basically a hack working around limitations of the current UNIX shells. They only add latency.

Whereas rtx manipulates your $PATH directly, at least when you do rtx global ... – I haven’t read its code about how does it handle entering a project directory that has a .tool-versions file. Likely does the same though.

1 Like
17

Update:

First of all, thank you all so much for your help.

As some suggested, the problem appears to be an ARM/X86 issue with Brew. How did this come about? When I got my new M2 Mac I used Apple’s Migration Assistant to migrate everything from an Intel Mac to the new machine. Frankly, I didn’t think it would work but it managed to migrate Postgres, MacVim and pretty much everything I use day-to-day …including Brew. Brew seemed to be working fine but little did I realise it was running in Rosetta mode. This didn’t appear to affect anything I installed with Brew …until I tried running my old Phoenix project on the new machine.

Reinstalling Brew per the official website instructions and then reinstalling the latest Elixir with Brew (which also installs the Erlang dependency) fixed everything.

It’s an unusual set of circumstances but I am sure some others will have the same problem.

4 Likes
18

Glad you fixed it!

And yeah it’s a rather common problem, people periodically get caught off-guard and it seems Apple really could have done a better job at surfacing the potential problems and not just have its terminal app silently accept Rosetta without any sort of information.

19

Glad you fixed it!

I’m using a MacBook Pro with M1 chip and met same error.

I came across the same problem after ham-handedly messed up my earlier installation of Elixir/Erlang. I fixed it by re-installing using MacPorts.

Earlier, I tried installing Elixir/Erlang using asdf, while Elixir/Erlang were successfully installed, Phoenix failed to run. That was when I came across this error:

  • Application ssl exited: exited in: :ssl_app.start

Before trying asdf, I tried installing Elixir/Erlang with other approaches, including using homebrew. None of them worked. All the error messages involved some crypto or openssl package. Although I found some really old posts about problems with openssl on MacOS and certain versions of Elixir in the homebrew repo, I didn’t dig any deeper.

All I’m saying is if anyone finds this post in the future, you can also try macports, maybe that’ll fix it.