Following Elixir Getting Started guide fails to deploy

I’m having trouble deploying a simple Phoenix app, and stepped back to following Getting Started · Fly Docs exactly to figure out where I went wrong.

However following the instructions from the tutorial and having fly launch set up a DB times out.

I ran:

mix phx.new totallyvanilla-server
fly launch

and then changed the settings to create a Postgres DB.

Building and pushing the container appears to succeed, but then I get output like this:

Watch your deployment at https://fly.io/apps/totallyvanilla-server/monitoring

Provisioning ips for totallyvanilla-server
  Dedicated ipv6: 2a09:8280:1::35:211b:0
  Shared ipv4: 66.241.124.233
  Add a dedicated ipv4 with: fly ips allocate-v4

Running totallyvanilla-server release_command: /app/bin/migrate

-------
 ✖ Failed: error waiting for release_command machine 24d890171b1587 to finish running: timeout reached waiting for machine's state to change
-------
Checking DNS configuration for totallyvanilla-server.fly.dev
Error: release command failed - aborting deployment. error waiting for release_command machine 24d890171b1587 to finish running: timeout reached waiting for machine's state to change
Your machine never reached the state "%s".

You can try increasing the timeout with the --release-command-timeout flag

Before failing, it worked through a couple machine states then sits and spins with this:

 ⠹ Waiting for 24d890171b1587 to have state: destroyed

(which is weird, why are we waiting for the machine that just got spun up to be destroyed?)

Logs look unremarkable, nothing is logged after the machine starts successfully:

2024-05-10T18:10:19.089 runner[24d890171b1587] sjc [info] Pulling container image registry.fly.io/totallyvanilla-server:deployment-01HXHV3RCYC6A1YNMR6AV5DANG
2024-05-10T18:10:23.075 runner[24d890171b1587] sjc [info] Successfully prepared image registry.fly.io/totallyvanilla-server:deployment-01HXHV3RCYC6A1YNMR6AV5DANG (3.985978346s)
2024-05-10T18:10:24.059 runner[24d890171b1587] sjc [info] Configuring firecracker
2024-05-10T18:10:24.192 app[24d890171b1587] sjc [info] [ 0.037398] PCI: Fatal: No config space access function found
2024-05-10T18:10:24.393 app[24d890171b1587] sjc [info] INFO Starting init (commit: d772ddd9)...
2024-05-10T18:10:24.454 app[24d890171b1587] sjc [info] INFO Preparing to run: `/app/bin/migrate` as nobody
2024-05-10T18:10:24.460 app[24d890171b1587] sjc [info] INFO [fly api proxy] listening at /.fly/api
2024-05-10T18:10:24.468 app[24d890171b1587] sjc [info] 2024/05/10 18:10:24 INFO SSH listening listen_address=[fdaa:0:3887:a7b:2ad:8ae1:b8bf:2]:22 dns_server=[fdaa::3]:53
2024-05-10T18:10:24.474 runner[24d890171b1587] sjc [info] Machine created and started in 5.387s

Any insights on what’s going on here? Is there another source of logging I’m not finding that could shed some light on what’s failing?

It sure seems like it should be easy to follow the tutorial and get an app deployed. I’ve tried this several times in a couple regions and with increased timeouts with no success.

For what it’s worth, this feels like a problem with the automated DB provisioning and setup in fly launch. If I do mix phx.new --no-ecto my-noecto-app && fly launch and accept the default config, launch quickly succeeds.

Hi… This is the one part of your adventure that isn’t weird, actually, :thought_balloon:. The release_command executes in an ephemeral machine, one which has auto_destroy enabled.

(Typically, it just runs your migrations—and then vanishes away.)

Yes. It was fairly easy when I tried, a few months ago, but not entirely smooth. And you might have bumped into some temporary platform glitches; it’s been a rough week for those.

sjc was undergoing maintenance today. What was the other region you attempted?

It’s also good to check the database’s logs in this situation, although I suspect there are multiple problems overlapping…

$ fly logs -a totallyvanilla-server-db

(I’m guessing at the name. Use fly apps list to see the full menu.)

Other things that might give you a better idea of what exists already, what needs to be repaired, etc.:

$ fly apps list
$ fly status
$ fly releases
$ fly secrets list  # should have DATABASE_URL
$ fly m list
$ fly m list     -a totallyvanilla-server-db
$ fly pg connect -a totallyvanilla-server-db

Hope this helps a little!

Added elixir, postgres

The release_commandexecutes in an ephemeral machine, one which has auto_destroy enabled.

Oh that makes sense, thanks.

sjc was undergoing maintenance today. What was the other region you attempted?

sea – I was mostly using sea since it’s the default for me.

After fiddling with this a bunch more, I think it’s something broken in fly launch related to naming.

I was able to deploy my app by changing the app name (and its enclosing directory name) to a unique name that fly would accept, and not changing the default name proposed by launch.

On the other hand, I can get a blank app template to fail to deploy by changing the default name (maybe the name used needs to include dashes?)

Not the most confidence inspiring experience…

1 Like

Interesting distinction… Thanks for the follow-up report! There was a recent commit to flyctl involving default names, if I remember correctly, so perhaps this was an unintended side effect.

A little while ago, Fly solicited comments about flyctl’s details; you might consider appending a quick note:

1 Like

Added flyctl

Hi! we made a change recently that affected how apps were named via fly launch, opting to fail if a derived name (via fly.toml or directory name) is already taken.

This shouldn’t have anything to do with an existing app failing to deploy via fly deploy, however. I fear these issues are unrelated.

1 Like

What version of phoenix are you on? This actually looks like you generated an invalid app with an old version of phx.new. For a long time now we enforce validation on the generated directory name: for example:

mix phx.new totallyvanilla-server
** (Mix) Application name must start with a letter and have only lowercase 
letters, numbers and underscore, got: "totallyvanilla-server". 
The application name is inferred from the path, if you'd  like to explicitly
 name the application then use the `--app APP` option.

So my guess is the mix release command that fly launch runs for you is generating an invalid release because the parent directory is not a valid. Please try renaming the parent directory to totallyvanilla_server and report back. Thanks!

Oops, up to date I believe (1.7.12), but I see why you’d think that, and my mistake… I committed the sin of changing my pasted text from what I ran. My app was originally named ‘server’ and I was like, oh, I should give that a better name.

I’m still able to make a fresh app fail to deploy by doing the following:

  1. mix phx.new server
  2. cd server
  3. fly launch
  4. Yes, tweak settings. Set app name to “test-service-name-server” and add a Postgres DB (development single node) named “test-service-name-server-db” in the config web page
  5. Confirm settings and wait

This sits and spins and then times out for me. So maybe the issue is simply that a Phoenix app named ‘server’ fails to deploy when you change the name to be unique on the fly side?

Here’s a gist with the full output: Phx.new and fly launch output that fails to deploy · GitHub

I’m using:

> mix phx.new --version
Phoenix installer v1.7.12

> elixir --version     
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit] [dtrace]

Elixir 1.16.2 (compiled with Erlang/OTP 26)

That is the issue :slight_smile:
server is invalid and we should raise on phx.new because for releases we generate a bin/server script that starts the phoenix server by calling the release script(and is the entrypoint in the generated Dockerfile that phoenix generates with mix phx.gen.release --docker. When you run mix release (or when the Dockerfile does), a bin/[otp app name] script is generated, so by using server as the app name, the phoenix shim essentially overwrites the mix one, or vice versa. In either scenario, the app won’t fail to start properly. The shell script will either infinite loop, or start the release without starting the webserver, which would lead to an unhealthy machine. I opened an issue on phoenix so we can raise in this case:

Makes sense. Thanks for following up!