Your MongoDB service was affected by the ongoing platform disruption. The logs show MongoDB is unable to start due to a Linux kernel 6.19 incompatibility with the MongoDB version you're running. We are currently in recovery, automatically redeploying unhealthy services. If your MongoDB does not recover on its own, try triggering a manual redeploy from the dashboard. If it continues to crash with the same kernel error, you may need to upgrade your MongoDB image to a version that supports kernel 6.19+.

that mean i no need do everything and wait railway fix that ?

please answer my question

Should receive a fix once Railway comes online for everyone. Some users remain impacted

Your MongoDB image isn't pinned to a specific version, which is unfortunately what caused this issue. Redeploying your service changed the minor version which surfaces errors like this.

You'll need to update the Docker image tag in your MongoDB service's Settings tab to a compatible version (e.g., mongo:8 or mongo:7-jammy) and redeploy. The community here should be able to help you diagnose further.

still crash

please check

PLEASE FIX ASAP

Same here since following the outage on 19th May, my Postgres service is stuck in a crash loop with the error: failed to exec pid1: No such file or directory. Volume ID: vol_wlhrlmbk6hsatnvc. I see they are stating that it has been fixed, it is not for me and other it seems.

This can be fixed with a redeploy of your PostgreSQL service. I went in and manually issued one for your service so that should resolve things 🙂. If you have any other issues, please open your own thread with us and we can dig in.

how abount me bro . my issues still not resolved

please fix this issue, still not resolved

THIS ISSUE VERY LONG TIME NOT RESOLVED YET PLEASE ACTION ASAP

ANY IDEA . STILL NOT RESOLVED

are you there

I had the same issue; my image was set to mongo:8.0 - i understood that you would want to use at least 8.2 for the native fix of that issue. If you don't want/can't upgrade to that, you need to add a variable to your release with the name GLIBC_TUNABLES and a value of glibc.pthread.rseq=0 (tldr, railway upgraded their linux kernal bases and the newer versions dont play nice with mongo 8.0's older modules)

At this point I would not keep redeploying the same image. You have two practical fixes:

1. Preferred: upgrade the image from mongo:8 to the offered 8.3.2 update in Railway, then redeploy.
2. Temporary workaround: add this service variable to the MongoDB service and redeploy:

GLIBC_TUNABLES=glibc.pthread.rseq=0

The crash is not caused by your app service. It is MongoDB itself failing before it starts because MongoDB 8.x has a known incompatibility with Linux kernel 6.19+ related to TCMalloc/rseq.

If 8.3.2 still crashes, try the GLIBC_TUNABLES workaround next, or pin to a known working tag such as mongo:7.0.34-jammy only after taking/keeping a volume snapshot.