New app not deploying to specified region

New app not deploying with “Failed due to unhealthy allocations”, and what’s striking is the logs show regions other than the specified sjc.

The followings logs show both syd and gru as targets:

2022-05-16T23:30:25Z app[34d87fb3] syd [info]Starting init (commit: aa54f7d)...
2022-05-16T23:30:25Z app[34d87fb3] syd [info]Preparing to run: `/app/bin/server` as nobody
2022-05-16T23:30:25Z app[34d87fb3] syd [info]2022/05/16 23:30:25 listening on [fdaa:0:654f:a7b:9e6b:34d8:7fb3:2]:22 (DNS: [fdaa::3]:53)
2022-05-16T23:30:26Z app[34d87fb3] syd [info]Reaped child process with pid: 555, exit code: 0
2022-05-16T23:30:30Z app[34d87fb3] syd [info]Reaped child process with pid: 576 and signal: SIGUSR1, core dumped? false
2022-05-16T23:30:30Z app[34d87fb3] syd [info]23:30:30.229 [info] Running StinsonWeb.Endpoint with cowboy 2.9.0 at :::4000 (http)
2022-05-16T23:30:30Z app[34d87fb3] syd [info]23:30:30.232 [info] Access StinsonWeb.Endpoint at
2022-05-16T23:32:29Z proxy[34d87fb3] sjc [error]Error 1: Undocumented
2022-05-16T23:36:17Z runner[85bfd083] gru [info]Starting instance
2022-05-16T23:36:17Z runner[85bfd083] gru [info]Configuring virtual machine
2022-05-16T23:36:17Z runner[85bfd083] gru [info]Pulling container image
2022-05-16T23:37:19Z runner[85bfd083] gru [info]Unpacking image
2022-05-16T23:37:27Z runner[85bfd083] gru [info]Preparing kernel init
2022-05-16T23:37:28Z runner[85bfd083] gru [info]Configuring firecracker
2022-05-16T23:37:29Z runner[85bfd083] gru [info]Starting virtual machine
2022-05-16T23:37:29Z app[85bfd083] gru [info]Starting init (commit: aa54f7d)...
2022-05-16T23:37:29Z app[85bfd083] gru [info]Preparing to run: `/app/bin/server` as nobody
2022-05-16T23:37:29Z app[85bfd083] gru [info]2022/05/16 23:37:29 listening on [fdaa:0:654f:a7b:1f63:85bf:d083:2]:22 (DNS: [fdaa::3]:53)
2022-05-16T23:37:30Z app[85bfd083] gru [info]Reaped child process with pid: 555, exit code: 0
2022-05-16T23:37:34Z app[85bfd083] gru [info]23:37:34.321 [info] Running StinsonWeb.Endpoint with cowboy 2.9.0 at :::4000 (http)
2022-05-16T23:37:34Z app[85bfd083] gru [info]23:37:34.324 [info] Access StinsonWeb.Endpoint at
2022-05-16T23:37:34Z app[85bfd083] gru [info]Reaped child process with pid: 576 and signal: SIGUSR1, core dumped? false
2022-05-16T23:41:31Z runner[85bfd083] gru [info]Shutting down virtual machine
2022-05-16T23:41:32Z app[85bfd083] gru [info]Sending signal SIGINT to main child process w/ PID 516
2022-05-16T23:41:32Z app[85bfd083] gru [info]BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
2022-05-16T23:41:32Z app[85bfd083] gru [info]       (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
2022-05-16T23:41:33Z app[85bfd083] gru [info]Main child exited normally with code: 0
2022-05-16T23:41:33Z app[85bfd083] gru [info]Reaped child process with pid: 578 and signal: SIGUSR1, core dumped? false
2022-05-16T23:41:33Z app[85bfd083] gru [info]Starting clean up.
2022-05-16T23:43:04Z proxy[34d87fb3] sjc [error]Error 1: Undocumented

Not sure what’s going on here…

My latest attempt to deploy has my primary app in hkg and an Oban job running in syd.

fly regions list

Region Pool: 
Backup Region: 

Happy to do what I can to get you up and running!

Reviewing other similar issues, it would seem that this indicates our proxy is having difficulty connecting to your app. It’s also possible that the different regions displayed in your logs indicate the same thing.

I’d definitely recommend double-checking your fly.toml against your deploy logs (which you can run at LOG_LEVEL=debug for more verbosity) to ensure that your app is configured to listen on the right ports and binding to the right IP address.

I hope this helps-- please let us know if you’re stuck; we’re always happy to take a closer look.

1 Like

Several issues were preventing me from a successful Multi-Environment Deployment.

To remedy my initial, multi-region issue posted above, I wound up destroying the app and recreating, while ensuring I selected sjc and avoided any option that might denote multi-region. This seems to have worked.

Second, and most importantly, I mistook the -a <app-name> argument of fly deploy as a way to specify a target toml file.

In preparing for multiple environments, I had created the following:

fly.toml -> fly.staging.toml
fly.toml -> fly.production.toml (with production specific edits, of course)

Only after scouring the docs did it occur to me that I should be using -c <toml-file> to deploy.

@eliwould the -a argument behave as outlined were I to merge fly.staging.toml and fly.production.toml back into a single file? No, according to the docs. The -a overrides the “app name” definition and is top-level.

Thanks for chiming in. This one stings.