a year ago
We have long-running (<5min) jobs that kick off from webhooks, which politely return HTTP responses right away, but keep processing.
So I want to catch SIGTERM and allow them to complete, then exit 0.
23 Replies
a year ago
few hours
a year ago
n/a
Thank you. 1hr is well more than enough.
I assume this will not change any time soon? (If so, a warning would be great)
a year ago
I don't see why we would change it, a lot of customers use it
Fantastic. Thanks for the info.
One small feedback: this config was hard to find btw, b/c I was looking all over "deployments" and "zero downtime" but finally found it here: https://docs.railway.com/reference/variables
a year ago
did you use the search bar?
I did. but my search terms (i think mainly "deployment" etc) weren't hitting that, at least i didn't notice
a year ago
where else in the docs do you think it would be applicable to mention it?
Hmm. Definitely I was hoping for "zero downtime" hits.
e.g.
https://docs.railway.com/guides/healthchecks-and-restarts#configure-healthcheck-path
https://docs.railway.com/reference/healthchecks
a year ago
I don't think the variable has much to do with zero downtime though?
a year ago
your new service would have already come online regardless of that variable
A bit subtle I suppose.
For the semantics of my project, SIGTERMing a running container, even if there are no unresponded HTTP requests, or no open TCP sockets, means downtime. The long job could be cut in half.
a year ago
I'm just realizing I've mentioned the wrong variable here -
your new service would have already come online regardless of that variable
while this is true, in my case the new deployment would be completely unaware of the active job. (Note: it could be designed to, but that's a bit overkill in my case)
a year ago
it says overlap when it should be draining
I'm sorry, I'm confused.
Such as in this thread: https://discord.com/channels/713503345364697088/1290350655222841345/1290354036062818397
I see I can arbitrarily extend the life of the old deployment with RAILWAYDEPLOYMENTOVERLAP_SECONDS
but all I need (which I believe is exclusive in behavior to that one) is for the new deploy to come up as normal, but the old deploy to (possibly) hang on SIGTERM for a few minutes, to be decided by the old deploy app at runtime.
a year ago
you want draining, the variable you asked about originally
a year ago
I don't have an exact time, so I'm safely saying a few hours
a year ago
!s
Status changed to Solved brody • about 1 year ago