Segmentation Fault despite no change to my service in almost a month

Hey folks

Since 7am ET today my service has been continuously restarting due to:

2023-01-18T16:38:11.382 app[b9a18b6c] ewr [info] Segmentation fault

Did something on’s platform change?

I haven’t made a deploy for 22 days so I don’t think it’s due to my service itself.

1 Like

I’m encountering this too since last night! I thought it was just me. But I can’t deploy any new releases, even for a new app. I’ve already emailed our support, and I think they’re looking into it. I am unsure.

All my fly apps are stuck in an infinite deploy loop.

1 Like

@dennisdang did you get a solution to this in the end?

I just ran my docker instance locally, runs fine.

Pushed a new commit to see if a fresh deploy would work. Sadly it didn’t :confused:

Can any folks shed some light on this?

SOLVED. Following this worked for me:

I also tried using different docker bases and pushing new a version of my app but none of that worked.

Thank you @mwills !!! :trophy:

1 Like

I solved it by switching to a node version < 18 as well. But setting the engine type to binary might be the better option to use the new node versions.

It’s still so strange to have this issue occur only now.

Yeh there’s got to be something that changed in’s stack in order for this to start occuring now. ¯_(ツ)_/¯

1 Like

I don’t think it’s Fly either because I deployed the same app onto Render and got the same segfault. It’s the docker image (node + linux flavor). I would think docker images are immutable. But iirc, it might be possible to publish a new image under the same semver version. The real diff is the commit hash. :frowning_face:

Just did some reading about SEGFAULT - that explains why I couldn’t reproduct it. I’m on M1, so I could not reproduce this locally.

Again, so so strange that this just happened to us both now, especially as I haven’t made a deploy in about a month prior to it crashing. Perhaps my app could moved to some other hardware that didn’t agree with it.

1 Like