When I check the logs using flyctl logs, I see the following:
2022-04-09T22:43:24.108 runner[606b514f] vin [info] Shutting down virtual machine
2022-04-09T22:43:24.108 runner[606b514f] vin [info] Shutting down virtual machine
2022-04-09T22:43:24.108 runner[606b514f] vin [info] Shutting down virtual machine
2022-04-09T22:43:24.108 runner[606b514f] vin [info] Shutting down virtual machine
2022-04-09T22:43:24.108 runner[606b514f] vin [info] Shutting down virtual machine
2022-04-09T22:43:24.134 app[606b514f] vin [info] Sending signal SIGINT to main child process w/ PID 515
2022-04-09T22:43:24.134 app[606b514f] vin [info] Sending signal SIGINT to main child process w/ PID 515
2022-04-09T22:43:24.134 app[606b514f] vin [info] Sending signal SIGINT to main child process w/ PID 515
2022-04-09T22:43:24.134 app[606b514f] vin [info] Sending signal SIGINT to main child process w/ PID 515
2022-04-09T22:43:24.134 app[606b514f] vin [info] Sending signal SIGINT to main child process w/ PID 515
However, I don’t see any Node.js stack-trace (e.g … unhandled exception or something like that). Is this an issue with my node.js application or do I need to configure something in fly.io to prevent my comtainer from shutting down?
based on my experimentation there isn’t anything wrong with your app - fly.io appears to kill apps if they are on low tier systems (shared-cpu-1x) - @jsierles if this could be documented it would remove ambiguity and give us more confidence in the platform…
I just saw this in our app: It was running totally fine in production for seven months and then out of the blue: SIGINT. We’re on a shared-cpu-8x@2048MB plan, so if it is true that those can be killed at random times, it would be good to know. Or could there be any other reasons for that?
Hi… Yes, it’s true, your Machines can be shut down without advance warning—other than the SIGXXX itself—and this is part and parcel of the normal operating regime of the platform.
(You’re not the first person to guess otherwise, though.)
This inherently holds for all Machine classes, not just shared, incidentally.
See the following for more background on why this is essential and what constraints you can rely on (esp. when maintaining a database cluster):
More broadly, Machines aren’t intended to be VPSes, but rather to lean more toward Amazon Lambda in terms of disposability. (This is my understanding from what Fly.io people have said themselves, in the past.) To use the platform effectively, you need to architecture around that…
Thank you for the quick response and all the info! Glad to see confirmation that this is expected behavior and the reasons for it totally make sense to me.
Luckily in our case, everything resolved itself without us doing anything, so I guess we got that part right
