I’ve compiled as much info as possible in a gist here - but the recap is:
it’s a totally “empty” mix phx.new . --app battery_rehab
docker compose build works
docker compose run --rm phoenix mix test works
docker compose up ends phoenix with error 139
I’ve tried to google for it - but somehow I’ve managed to land both feet right into unchartered territory (with the closest thing that I could muster was that rebuild assets.deploy fail) which probably speaks to the utter n00bness of me at all dabbling with 1.6 and containers (coming from ruby-land - and been wanting to for nearly 4/5 years on now without getting that well-deserved breakthrough - it’s tough)
Hoping one of you guys in here knows what kind of animal a ‘139’ is -
I’m on an M1 (Apple) - and I won’t deny that it sat with me for nearly 8 months before I tried to do any good with it (mostly because things like brew turned out to be such a hazzle )
but the container is running off of elixir:latest (the Dockerfile gives that away in line 1) but what “platform” has never been of much interest to me - I use it very frequently with Rails containers
but I have to hurry to admit that I probably should care! And not knowing how to tell Docker to use a different “platform” may be an issue -
by the looks of it - the “platform” is aarch64
root@e2982d09dc8b:/app# uname -a
Linux e2982d09dc8b 5.10.25-linuxkit #1 SMP PREEMPT Tue Mar 23 09:24:45 UTC 2021 aarch64 GNU/Linux
dug into the ‘container-chain’ and it turns out that it all comes down to a Debian of sorts
Important lesson too! Not all platforms are made equal
(not that I didn’t know that - from building on Symbian60 in the late '90’s - but I kind’a guessed that with Docker being an “abstraction layer” this sort of was a thing of the past) - guess not
using https://asdf-vm.com for elixir/erlang/node and just running natively no containers is pretty big here in elixir land, so you can try that some adventurous day
I’m a big fan of asdf for sure - it did very well in ruby-land too, allowing me to context switch between 10+ year old projects and newly minted ones in a blink of an eye - or should I say cd
Maybe the communities around projects like nokogiri have it ironed out by now but going 10/12 months back the M1 platform was in fact a terrible place to be running anything native that would require compiling open source stuff hence the “acquired taste” for containers
Just wanted to say thanks for posting this thread. I hit the exact same error. I thought for sure it would be some obscure thing I’d have to Google for a while. But, nope, the question and answer were right there on the front page of Elixir Forum!
Docker is only a set of restrictions in terms of system calls, process visibility, filesystem access and networking. There is no hypervisor or virtual CPU.
I’m also on a Mac M1, and running in container to bypass the non-availability of M1 builds of a lot of OSS.
I seem to be running into a similar issue with Phoenix 1.6.4 with a freshly minted app. I tried using
FROM hexpm/elixir:1.13.0-erlang-24.1.7-ubuntu-focal-20210325
If I run esbuild natively, it works. If I run esbuild in container, it segfaults. esbuild seems to be using esbuild-darwin-arm64 natively, but esbuild-linux-arm64 in container. Not sure if this is the root cause.
When I run mix phx.server, it just seems to hang. I never get the “[info] Running Crypto.Endpoint with cowboy 2.9.0 at 0.0.0.0:4000 (http)” output.
I have a feeling this is being caused by esbuild (maybe the watchers), but don’t know how to confirm that.
I’m an erlang/elixir noob, but otherwise pretty experienced. I’m not sure how to go about finding the point at which such a crash might be happening (if it is). Any pointers to the process of diagnosis would be just as helpful as an actual answer. I’m happy to get my hands dirty with low level detail on elixir/erlang/otp.
I get the same hanging behaviour that I do in container. The difference is that
mix assets.deploy
works natively, but segfaults in container
So maybe this is an issue with the M1 rather than containerization
How would I go about finding out why/where it’s hanging. Is there a way to log events on the request path? or attach a debugger? some other tool that I’m unaware of?
Looks like part of the problem was with the app name. I guess “crypto” is an existing name somewhere. I changed the app name and it’s running natively now.
In container, I still get a segfault, but now I get the output
“[info] Running MyAppWeb.Endpoint with cowboy 2.9.0 at 127.0.0.1:4000 (http)” output.
so at least it’s getting further. My guess is it’s still something to do with esbuild, darwin vs linux.
It turns out phx.new was generating an older version of esbuild (0.13.5). The new version 0.14.0 appears to be working correctly in container. It’s also the default version used in the current version of the phoenix esbuild installer.