a month ago
getting 502 bad gateway
on first deployment it is not getting any kind of the issue but from last two days getting this error I do not know why facing that issue could please help me to find out the issue
Attachments
8 Replies
a month ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open brody • about 1 month ago
a month ago
Could you check your logs for any errors that you see when you visit the website ?
Then post it here, this would help me debug the issue you are facing.
a month ago
Starting Container
--
ENV LOG: {
--
NODE_ENV: 'production',
--
FRONTEND_URL: 'https://resumefrontend-production-678e.up.railway.app';,
--
SESSION_SECRET: 'SET',
--
PORT: '5000',
--
MONGODB_URL: 'SET'
--
}
--
Warning: connect.session() MemoryStore is not
--
designed for a production environment, as it will leak
--
memory, and will not scale past a single process.
--
Connecting to MongoDB...
--
MongoDB connected successfully
--
Server running on 0.0.0.0:5000
--
Environment: production
--
Health check available at: http://0.0.0.0:5000/health
--
Server is ready to accept connections
--
Health check requested on /health
--
Health check requested on /health
--
Internal health check passed: 200
--
Stopping Container
--
SIGTERM received, shutting down gracefully...
--
Server closed
--
Session store closed
--
MongoDB connection closed
see here the container is start but close automatically with out showing any error
a month ago
might something be telling it to shut down? its shutting down to SIGTERM, which indicates that something might be telling it to shut down
quote from gnu.org:
Macro: intSIGTERM
The SIGTERM signal is a generic signal used to cause program termination. Unlike SIGKILL, this signal can be blocked, handled, and ignored. It is the normal way to politely ask a program to terminate.
The shell command kill generates SIGTERM by default.
also, where is this log coming from? could you provide some more information?
vpai-grok
Starting ContainerJul 01 21:36:358b5f373eresume_backend--d6b0ed20ENV LOG: {Jul 01 21:36:358b5f373eresume_backend--d6b0ed20NODE_ENV: 'production',Jul 01 21:36:358b5f373eresume_backend--d6b0ed20FRONTEND_URL: 'https://resumefrontend-production-678e.up.railway.app';,Jul 01 21:36:358b5f373eresume_backend--d6b0ed20SESSION_SECRET: 'SET',Jul 01 21:36:358b5f373eresume_backend--d6b0ed20PORT: '5000',Jul 01 21:36:358b5f373eresume_backend--d6b0ed20MONGODB_URL: 'SET'Jul 01 21:36:358b5f373eresume_backend--d6b0ed20}Jul 01 21:36:358b5f373eresume_backend--d6b0ed20Warning: connect.session() MemoryStore is notJul 01 21:36:358b5f373eresume_backend--d6b0ed20designed for a production environment, as it will leakJul 01 21:36:358b5f373eresume_backend--d6b0ed20memory, and will not scale past a single process.Jul 01 21:36:358b5f373eresume_backend--d6b0ed20Connecting to MongoDB...Jul 01 21:36:388b5f373eresume_backend--d6b0ed20MongoDB connected successfullyJul 01 21:36:388b5f373eresume_backend--d6b0ed20Server running on 0.0.0.0:5000Jul 01 21:36:388b5f373eresume_backend--d6b0ed20Environment: productionJul 01 21:36:388b5f373eresume_backend--d6b0ed20Health check available at: http://0.0.0.0:5000/healthJul 01 21:36:388b5f373eresume_backend--d6b0ed20Server is ready to accept connectionsJul 01 21:36:388b5f373eresume_backend--d6b0ed20Health check requested on /healthJul 01 21:36:398b5f373eresume_backend--d6b0ed20Health check requested on /healthJul 01 21:36:398b5f373eresume_backend--d6b0ed20Internal health check passed: 200Jul 01 21:36:437decaf61resume_backend--16242b39Stopping ContainerJul 01 21:36:477decaf61resume_backend--16242b39SIGTERM received, shutting down gracefully...Jul 01 21:36:477decaf61resume_backend--16242b39Server closedJul 01 21:36:477decaf61resume_backend--16242b39Session store closedJul 01 21:36:477decaf61resume_backend--16242b39MongoDB connection closedsee here the container is start but close automatically with out showing any error
a month ago
My first thought looking at the logs was serverless mode, as it sends a SIGTERM, but the time difference doesn't make sense also the app is establishing an active connection with a db so serverless shouldn't work anyway i think.
The SIGTERM is being sent by railway i am confident in that. The issue is likely due to a misconfigured healthcheck as SIGTERM is sent right after it
Can you remove the healthcheck path from your deployment by going into your app Settings -> Healthcheck Path
a month ago
EDIT 1:
timing looks off for it to be serverless, the railway wiki says:
"Inactivity is based on the detection of any outbound packets, which could include network requests, database connections, or even NTP. If no packets are sent from the service for over 10 minutes, the service is considered inactive."
that timing looks way shorter than 10 minutes, considering startup and shutdown all happen within the same minute
will update when i think of more stuff
EDIT 2:
is it possible that it might just be deployment teardown? dosent exactly make sense, but i found a mention of sigterm there.
"Once the new deployment is active, the previous deployment is sent a SIGTERM signal and given time to gracefully shutdown before being forcefully stopped with a SIGKILL."
EDIT 3:
if you could impliment a hook on SIGTERM, that could give us all more information
teesh3rt
EDIT 1:timing looks off for it to be serverless, the railway wiki says:"Inactivity is based on the detection of any outbound packets, which could include network requests, database connections, or even NTP. If no packets are sent from the service for over 10 minutes, the service is considered inactive."that timing looks way shorter than 10 minutes, considering startup and shutdown all happen within the same minutewill update when i think of more stuffEDIT 2:is it possible that it might just be deployment teardown? dosent exactly make sense, but i found a mention of sigterm there."Once the new deployment is active, the previous deployment is sent a SIGTERM signal and given time to gracefully shutdown before being forcefully stopped with a SIGKILL."EDIT 3:if you could impliment a hook on SIGTERM, that could give us all more information
a month ago
You need to keep "502 bad gateway" into context. If it's a new deployment then app should respond still.
It's not just about SIGTERM here. That is just a clue.
a month ago
"The HTTP 502 Bad Gatewayserver error response status code indicates that a server was acting as a gateway or proxy and that it received an invalid response from the upstream server.
This response is similar to a 500 Internal Server Error response in the sense that it is a generic "catch-call" for server errors. The difference is that it is specific to the point in the request chain that the error has occurred. If the origin server sends a valid HTTP error response to the gateway, the response should be passed on to the client instead of a 502 to make the failure reason transparent. If the proxy or gateway did not receive any HTTP response from the origin, it instead sends a 504 Gateway Timeout to the client."
Common causes:
Backend server is down or unreachable
Backend server crashed or timed out
Network issues between proxy and backend
Misconfigured proxy or load balancer
Backend server returned invalid or malformed response
a month ago
not to be rude but let's focus on solving the issue instead of explaining it using chatgpt