SvelteKit server not receiving SIGTERM when container stops

debashisbiswas

PROOP

8 days ago

SvelteKit has a graceful shutdown handler that is called after a SIGTERM or SIGINT: https://svelte.dev/docs/kit/adapter-node#Graceful-shutdown

I have implemented this handler and have confirmed it works locally by building a production build, starting it, and sending it a SIGTERM. When testing locally, the "initializing" message is shown on startup and the shutdown message is shown on shutdown. Here is my handler. The job queue is not relevant here but I'm including it because it's part of my code:

import { JobQueue } from '$lib/server/job-queue';
import type { ServerInit } from '@sveltejs/kit';

export const init: ServerInit = async () => {
    console.log('Initializing server...');

    const shutdown = JobQueue.init();

    process.on('sveltekit:shutdown', async (reason) => {
        console.log('sveltekit:shutdown from signal:', reason);
        await shutdown();
    });
};

On my Railway deployment, I see the initialization message when the server starts up, but I don't see the SIGTERM when the container is stopped in favor of a new deployment.

I am using node to start my server directly, rather than npm, as per https://docs.railway.com/deployments/troubleshooting/nodejs-sigterm-handling

Here is my deployment config:

{
  "$schema": "https://railway.com/railway.schema.json",
  "build": {
    "builder": "RAILPACK",
    "buildEnvironment": "V3"
  },
  "deploy": {
    "runtime": "V2",
    "numReplicas": 1,
    "startCommand": "node build/index.js",
    "healthcheckPath": "/",
    "preDeployCommand": [
      "npm run db:migrate"
    ],
    "sleepApplication": false,
    "useLegacyStacker": false,
    "ipv6EgressEnabled": false,
    "multiRegionConfig": {
      "us-west2": {
        "numReplicas": 1
      }
    },
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 10
  }
}

Solved$20 Bounty

Pinned Solution

andrewkat52

FREE

8 days ago

i think your problem is that railway's default draining time is 0 seconds so it sends sigterm to your container and immediately follows with sigkill which force kills the process before node can even run the sveltekit shutdown handler

fix thid by ading this as a service variable in your railway dashboard:

RAILWAY_DEPLOYMENT_DRAINING_SECONDS=30

this tells railway to wait 30 seconds between sigterm and sigkill, giving your handler time to actually execute

7 Replies

debashisbiswas

PROOP

8 days ago

Here's the end of my log for the last container that was stopped:

Attachments

image.png

debashisbiswas

PROOP

8 days ago

In this case, I would expect to see the log "sveltekit:shutdown from signal: SIGTERM"

debashisbiswas

PROOP

8 days ago

whereas on a local build, I am seeing the shutdown message as expected:

Attachments

image.png

andrewkat52

FREE

8 days ago

i think your problem is that railway's default draining time is 0 seconds so it sends sigterm to your container and immediately follows with sigkill which force kills the process before node can even run the sveltekit shutdown handler

fix thid by ading this as a service variable in your railway dashboard:

RAILWAY_DEPLOYMENT_DRAINING_SECONDS=30

this tells railway to wait 30 seconds between sigterm and sigkill, giving your handler time to actually execute

andrewkat52

i think your problem is that railway's default draining time is 0 seconds so it sends sigterm to your container and immediately follows with sigkill which force kills the process before node can even run the sveltekit shutdown handler fix thid by ading this as a service variable in your railway dashboard: RAILWAY\_DEPLOYMENT\_DRAINING\_SECONDS=30 this tells railway to wait 30 seconds between sigterm and sigkill, giving your handler time to actually execute

andrewkat52

FREE

8 days ago

source from docs : https://docs.railway.com/variables/reference

debashisbiswas

PROOP

8 days ago

Thank you! This seemed to be the fix. I configured this behavior via the teardown tab: https://docs.railway.com/deployments/deployment-teardown

It is a bit weird that the drain time defaults to zero, especially because it seems like my deployments been using a non-zero overlap time by default.

1

Status changed to Solved 0x5b62656e5d • 8 days ago

debashisbiswas

PROOP

7 days ago

I've been testing this out for a few days. I noticed that I can watch my old deployment's shutdown logs when switching to the new deployment. However, if I revisit the logs for the deployment later, my shutdown logs seem to be gone - perhaps Railway is deleting logs from after the SIGTERM?