bluejack
So, I deployed a new version of an api app to fly.io.
I get the error:
2024-10-13T02:31:06.101 app[5683974b736e18] sea [info] 2024/10/13 02:31:06 INFO SSH listening listen_address=[fdaa:9:8f2a:a7b:bcab:1ad4:8d17:2]:22 dns_server=[fdaa::3]:53
2024-10-13T02:31:08.230 app[5683974b736e18] sea [info] Runtime terminating during boot (terminating)
I add the config to look at the crash dump logs, I don’t see anything that looks like a smoking gun, but I honestly don’t know what most of the settings mean.
I referenced some other threads, and evaluated some different options, including elixir version. Nothing changes it.
I rolled back to an earlier version of the app. It still fails.
I tried deployments via my github workflow and also via my desktop, all results are the same.
I have changes some secrets, also, but could a secret crash the elixir runtime during boot without so much as a warning message? What else could be going on?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
bluejack
ANSWER: It WAS a configuration change that I had made. I had made the configuration change through the web console, and apparently there was a typo or cut and paste error of some sort.
Redeploying the change via the commandline fixed the issue.
I don’t know why no errors were written to the logs, however. My best guess is that because the error was happening in a child process, the fly.io logs don’t capture it. This seems unnecessarily confusing situation however.
Also Liked
zachallaun
Glad you figured it out!
Consider posting on the Fly.io community forum, which might get the situation in front of the eyes of some folks working there and lead to a better experience in the future.