[Bug?]: Yarn does not wait for child process on SIGTERM for a graceful shutdown.

[brian-xu-vlt]

Self-service

• I'd be willing to implement a fix

Describe the bug

(The code bellow describe the content of the repo available for reproduction)
With a simple express server handling a SIGTERM by waiting 3000ms before shutting down:

const express = require('express')
const app = express()

app.get('/', (req, res) => {
    res.send('Hello, World!')
})

const timeout = 3000;

function handle(signal) {
    console.log(`Received ${signal}, shutting server in ${timeout} ms`);
    return new Promise(resolve => {
        setTimeout(() => {
            console.log('End of timeout, shutting down server now.');
            resolve();
            process.exit(0);
        }, timeout);
    });
}

process.on('SIGTERM', handle);


app.listen(3000, () => {
    console.log('Server listening on port 3000')
})

Yarn will transmit the signal to its child process, which will call its handler function as expected.
But yarn will not wait for its child process to die before exiting. In a Docker context, it means the container will exit as well (yarn being PID 1)
So this container as a k8s pod will not gracefully shut down.

To reproduce

Clone repo and launch the container with Yarn:

git clone git@github.com:brian-xu-vlt/poc-yarn-issue.git
cd poc-yarn-issue
docker build -t poc . && docker run -it --rm -l 'poc' poc

In another terminal tab, kill the container:
docker kill --signal="SIGTERM" $(docker ps -q --filter=label="poc")
Will kill the container immediately, not waiting for 3000ms as expected.

---

For context, use NPM instead:
docker build -f Dockerfile.NPM -t poc . && docker run -it --rm -l 'poc' poc
In another terminal tab, kill the container:
docker kill --signal="SIGTERM" $(docker ps -q --filter=label="poc")
Will wait for 3000ms as expected.

Environment

Docker version 20.10.21, build baeda1f82a
with node:16.18.1-alpine image

yarn 3.3.1

Additional context

Can be reproduced locally too (i.e. without docker) by running yarn start and find the pid of yarn process, then send a SIGTERM to it. It will leave the underlying node process as an orphan process, which means its output after the 3000ms will go to the terminal in the prompt, after yarn has exited:

[JasonMan34]

This is actually an issue with yarn 1, that is caused when using yarn 3 because yarn 3 is spawned by yarn 1

[brian-xu-vlt]

This is actually an issue with yarn 1, that is caused when using yarn 3 because yarn 3 is spawned by yarn 1

Thanks for you reply. I believe these are two different issues: in my case the signal is well propagated to children (as opposed as the issue you linked), but the parent process (yarn) does not wait until the children properly exited following the signal to exit itself.
In the a Docker container context, it means the container shuts down right after yarn propagated the signal to its children as yarn is PID 1 and has exited.

[JasonMan34]

Sorry, I misunderstood the issue that I linked to

For me, the problem was that my my container was using the node:16.15-alpine image, which comes with yarn v1.22.19, where the problem exists

However, in yarn v3.3.1, the problem does not happen for me, and graceful shutdown is executed properly

To fix this, I added the following to the top of my Dockerfile:

RUN corepack enable
RUN corepack prepare yarn@3.4.1 --activate

[brian-xu-vlt]

Thank you so much! It does solve my issue 🙌
However I can't figure out the difference between:

RUN corepack enable
RUN corepack prepare yarn@3.4.1 --activate

And

RUN yarn set version berry
RUN yarn install

Using these two sets of instruction alternatively and running yarn -v shows the same 3.4.1 version.

Even getting the version inside my script shows me the right version with:

const yarnProcess = spawn('yarn', ['--version']);

yarnProcess.stdout.on('data', (data) => {
  const yarnVersion = data.toString().trim();
  console.log(`Yarn version: ${yarnVersion}`);
});

But the behavior is definitely different between both Dockerfile instruction 🤔

[JasonMan34]

The difference stems from the fact that yarn set version berry sets the local version of yarn, inside your project folder, not the global version

If you add this step after: RUN cd ~ && yarn -v, you will see that the global yarn version is still 1.x.x (That gets deployed with the node image)
When doing yarn set version berry, then yarn -v, what happens is that:

1. A global yarn instance (which would be version 1.x.x in this case) is spawned
2. The spawned yarn instance spawns another yarn instance, this time - a yarn v3.4.1 instance that is loaded from the local project directory
3. The spawned yarn (v3.4.1) instance does everything else (runs the script, or command, that was given to it)

The PID 1 process is still that yarn v1 instance, which fails to wait for a graceful shutdown

Running the corepack instructions basically installs yarn v3.4.1 globally. So the steps above still happen (A global yarn instance spawns a local yarn instance that executes the command), but this time the PID 1 process is a yarn v3 instance

[brian-xu-vlt]

Brilliant, thanks for the in depth explanation.