I noticed that my app got moved from “active apps” to “apps that haven’t been deployed.”
I’ve tried to redeploy it a couple times but it doesn’t seem to change the deployment status.
The last thing I see in the logs is:
Shutting down virtual machine
Sending signal SIGINT to main child process w/ PID 523
Any suggestions?
Maybe try running fly status and see what that says? From what you say, I’m guessing no vms will be listed at the bottom of that.
In which case (assuming you only need one vm) try running fly scale count 1 and that should start a new vm. It may take a minute. Try fly status now. Is there a vm listed?
Also now try fly logs again and see what the output is. Does the new vm start up? Does it stay running? Or is there an error/exception/fault shown there (which would explain why it can’t stay running and so instead shuts down).
Fly will retry X times to deploy and start the app but I assume eventually gives up, which would then result in the app showing as not being deployed.
Thank you very much for the suggestions!
fly status I don’t see any VMs and the status is pending
fly scale count 1
fly status again, still don’t see any VMs? (status is still pending)fly logs or try to look at the logs through the dashboard it waits forever without showing anything.Something seems different at least because the logs are not showing up. I don’t mind starting a new deployment if I need to, the main thing is that it would be nice to get the sqlite database off the attached volume if I can. Not the end of the world though.
Try running fly status --all and see if you have any failed VMs? When apps go to zero like this, it’s usually because of repeated VM failures.
It’s working now! I think the scale command must have done the trick, just maybe took awhile to go through. Thanks very much for your help!
Interestingly, in the same situation again. Ran fly status --all and this is what I see:
Nothing jumps out, curious about what DESIRED evict means. At this point I’m wondering what is killing the app in the first place, I think the problem is similar to this question about SIGINT.
Going to try fly scale count 1 again to kickstart the deployment.
So it looks like the scale and redeploy stuff didn’t help bring it back up yet. It’s possible that wasn’t the fix the first time because it could have been an exact 24 hour window between when it went down and came back up again. We’ll see if that is the case for the 2nd time.
Still curious about the SIGINT stuff that is making the app shut down in the first place. Main thing I am doing in my code that seems like a possible correlation is uploading images to Cloudinary at a higher rate while I am using it (like maybe one image per minute or two for ~20 minutes before it shuts down). Don’t see any problems with memory or any other resources through metrics though.
Yeah, running fly scale count 1 won’t actually fix anything. I just suggested that to see if it would result in getting a vm running at all, or show an error in the logs to say why not.
Don’t know about SIGINT. Guessing that’s simply a consequence of Fly’s system evicting the app and so then gets shut down. Why it’s doing that, not sure. Is this a paid account? If not, maybe it’s to do with that. Total guess. While you wait, you could try deploying in a different region to see if that helps. Again, no real reason why it would, but it’s worth a try.
Thank you! I appreciate your suggestions and I have definitely learned some helpful things for trying to troubleshoot the status of the app.
It is a paid instance but still very low tier. Other than recovering the sqlite database I have managed to deploy the app to a different region successfully, I guess I can see if it is evicted while I use it in the same way.
No problem.
That makes sense. Given that usage, personally I can’t see you are doing anything wrong at your end. If the metrics are still all good then maybe it was simply a temporary capacity issue in iad. Strange.
Yep, having now moved regions, if your app stays up, that’s likely it.
