I had created a Rails app(Rails 7 & Vue & PG), and ran flyctl launching, connected to PG.
It costs too much time for the step
Status: Image is up to date for heroku/pack:20
and it crashed then gave me:
Error failed building options: failed probing "personal": read tcp
Anyone knows how am I supposed to fix this?
---- Append:
I’ve failed 3 times running this. Just now, it works. Maybe just some network issue,
Problem solved, but are there any workaround to reduce the time cost of
Status: Image is up to date for heroku/pack:20
Thanks for the posting. What does fly version say for you? The latest flyctl should have given you a Dockerfile instead of using the Heroku buildpack.
The other issue is a connectivity problem. You can try fly doctor to see if it’s related to your Wireguard setup. If so, you can try fly wg websockets enable to see if that helps.
Which region are you in?
It’s <fly v0.0.328 darwin/arm64 Commit: be3bfa2 BuildDate: 2022-05-18T15:09:11Z>
I think I did a update before doing all this, and the region is hk.
I cannot reproduce the problem though, but thanks for your suggestion. I have more options to check the problem next time it fails
Sorry to bother you joshua I’m having another problem, just right now. I’ve released a version, it’s all good on the web pages. And then I had just added a migration file, then I ran flyctl deploy, it gave me this
Failed due to unhealthy allocations - not rolling back to stable job version 7 as current job has same specification
This happens because the ram is not quite enough for deploying? Cause I’m using the 256mb plan currently.
My fly check list content is:
Health Checks for pixel-china NAME | STATUS | ALLOCATION | REGION | TYPE | LAST UPDATED | OUTPUT -----------------------------------*----------*------------*--------*------*--------------*------------------------------------------------------------- 3df2415693844068640885b45074b954 | passing | 16a95cde | hkg | TCP | 7h5m ago | TCP connect 172.19.3.106:8080: Success[✓] | | | | | | | | | | | | 2c049ace173aa212ee0332a9b0a966d5 | critical | 16a95cde | hkg | TCP | 7h10m ago | dial tcp 172.19.3.106:3000: connect: connection refused[✓] | | | | | | | | | | | |
My fly status --all is:
Deployment Status
ID = 522377ba-bca7-580f-2880-16838672dfa2
Version = v7
Status = failed
Description = Failed due to unhealthy allocations - not rolling back to stable job version 7 as current job has same specification
Instances = 1 desired, 1 placed, 0 healthy, 1 unhealthy
Instances
ID PROCESS VERSION REGION DESIRED STATUS HEALTH CHECKS RESTARTS CREATED
25d044f6 app 7 ⇡ hkg stop complete 1 total, 1 critical 0 8m9s ago
d72eb1a2 app 6 hkg stop complete 1 total, 1 critical 0 5h51m ago
8ffb7b86 app 5 hkg stop complete 1 total, 1 critical 0 5h56m ago
33a72f05 app 4 hkg stop complete 1 total, 1 critical 0 6h17m ago
16a95cde app 3 hkg run running 2 total, 1 passing, 1 critical 0 7h21m ago
`
Can you post your fly.toml? If your web server listens on port 3000, you’ll need to set internal_port = 3000 in fly.toml.
Yes, it is 3000 port
fly.toml
fly.toml file generated for pixel on 2022-05-20T16:09:29+08:00
app = “pixel”
kill_signal = “SIGINT”
kill_timeout = 5
processes =
[env]
[experimental]
allowed_public_ports =
auto_rollback = true
[[services]]
http_checks =
internal_port = 3000
processes = [“app”]
protocol = “tcp”
script_checks =
[services.concurrency]
hard_limit = 25
soft_limit = 20
type = “connections”
[[services.ports]]
force_https = true
handlers = [“http”]
port = 80
[[services.ports]]
handlers = [“tls”, “http”]
port = 443
[[services.tcp_checks]]
grace_period = “1s”
interval = “15s”
restart_limit = 0
timeout = “2s”
[deploy]
release_command = “bin/rails db:migrate”
Running fly logs during a deploy should tell you whether the process is being killed off due to memory constraints. If so, you can raise the limit to 512. However, that will take you out of the free tier.