What is the max permitted value for RAILWAY_DEPLOYMENT_DRAINING_SECONDS?
nolanholden
HOBBYOP

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.

Solved

23 Replies

brody
EMPLOYEE

a year ago

few hours


brody
EMPLOYEE

a year ago

n/a


nolanholden
HOBBYOP

a year ago

Thank you. 1hr is well more than enough.

I assume this will not change any time soon? (If so, a warning would be great)


brody
EMPLOYEE

a year ago

I don't see why we would change it, a lot of customers use it


nolanholden
HOBBYOP

a year ago

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


brody
EMPLOYEE

a year ago

did you use the search bar?


nolanholden
HOBBYOP

a year ago

I did. but my search terms (i think mainly "deployment" etc) weren't hitting that, at least i didn't notice


brody
EMPLOYEE

a year ago

where else in the docs do you think it would be applicable to mention it?



brody
EMPLOYEE

a year ago

I don't think the variable has much to do with zero downtime though?


brody
EMPLOYEE

a year ago

your new service would have already come online regardless of that variable


nolanholden
HOBBYOP

a year ago

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.


nolanholden
HOBBYOP

a year ago

I agree it's not exactly related


brody
EMPLOYEE

a year ago

I'm just realizing I've mentioned the wrong variable here -


nolanholden
HOBBYOP

a year ago

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)


nolanholden
HOBBYOP

a year ago

RAILWAYDEPLOYMENTDRAINING_SECONDS is not the one you mentioned?


brody
EMPLOYEE

a year ago

it says overlap when it should be draining


nolanholden
HOBBYOP

a year ago

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.


nolanholden
HOBBYOP

a year ago

So i'd like to know the max time for both, I suppose


brody
EMPLOYEE

a year ago

you want draining, the variable you asked about originally


brody
EMPLOYEE

a year ago

I don't have an exact time, so I'm safely saying a few hours


nolanholden
HOBBYOP

a year ago

Ok, great.


brody
EMPLOYEE

a year ago

!s


Status changed to Solved brody about 1 year ago


Loading...