I had pocketbase Docker app, it was deployed 9 months ago and i didn’t touch it since then, it was running without any problem. Yesterday it suddenly got suspended and it wont start again, tried restarting, log are empty. I tried everything to run it again, moving to another organization, etc… I wouldn’t mind if it was shut down for whatever reason but my data is on Volume and I can’t access it, with no backup. Billing is also in range for free tier. No emails about this from fly.io. Any help?
Hi… Typically you can recover either by forking the volume or by making a new volume from a snapshot. What do fly m list and fly vol list show?
Aside: There is no free tier anymore (unless you signed up before 2024).
I forked the volumes, volumes are online, but i can’t attach them to anything.
fly m list:
fly vol list:
fly apps list:
Console tries to list from the other app i played around yesturday trying to solve the problem.
Here are screenshots from web dashboard:
flyctl takes the app name from fly.toml, which is probably what was causing it to look in the wrong place.
Try making an empty directory, cd into that directory, and then fly config save -a pb-falling-meadow-5240.
Then fly m list and fly vol list. The dashboard is neat, and everyone likes it, but it’s too limited for this kind of recovery…
Great… What I would do is override the start sequence for the existing Machine, so that you can use SFTP to retrieve the database files (to your local laptop/desktop).
After that, you can optionally try to get the Machine running back in its normal mode. There really should have been logs when you restarted it earlier.
Open a separate terminal window, cd into that same directory, and run fly logs (and leave that running during the subsequent steps).
Next, in the previous terminal, the following will override the CMD, without having to do a full redeploy:
$ fly m update --command 'sleep inf'
(If it was instead the entrypoint that was at fault, then this will take additional work.)
If that does start successfully, then SSH in and make sure that all the expected files are there, etc.—and then SFTP.
Wow, fly logs actually worked this time, so RAM memory is the problem? And I managed to restart it somehow, thank you sir!
Glad you got it working again! That’s referring to RAM on the underlying physical host machine. I.e., too many other Fly.io customers want to run simultaneously on that particular unit.
otp is showing a capacity crunch right now, in general, according to the (excellent) new system statistics:
https://community.fly.io/t/regional-capacity-in-machines-api-and-flyctl/24843
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.