Search for a command to run...
Yusuf Adeyemo is a DevOps Engineer from Nigeria. He loves helping startups deliver better software and provide more control over their environment and software development process with the help of modern tools and automation.
We’ve all been there. You spend hours perfectly tuning your OpenWrt configuration, setting up your captive portals, and hardening your firewall. Then, six months later, the system hangs. Why? Because
This article started from a tweet. Someone on Twitter said they "lowkey want to understand the technology behind Google Authenticator" and I dropped a quick reply - explaining that it's basically TOTP: your device and the server share a secret key, b...
Have you ever sat there waiting for your CodeBuild project to rebuild your entire Docker image... again? Even though you only changed a single line of code? Yeah, me too. And it's frustrating. Today, I'm going to show you how I reduced our Docker bui...
After you complete this article, you will have a solid understanding of: Why deploying Next.js SSR on Cloudflare is different from traditional hosting The real difference between Cloudflare Pages with next-on-pages and OpenNext adapter How the fre...
After you complete this article, you will have a solid understanding of: What L1, L2, and L3 constructs actually are and when to use each Why AWS created three different abstraction levels (and the hidden benefits) How to avoid the most common CDK...
Imagine this scenario: Your Node.js application is happily running, processing requests, interacting with databases, and then suddenly, it gets terminated. The system administrator decided it was time to scale down, or perhaps a critical error forced the application to exit. In any case, the application was in the middle of processing requests, writing data to a file, and now all of that is abruptly stopped. What happens to that data? What happens to your users' requests? The consequences of an abrupt shutdown can range from minor inconveniences to significant data loss, and degraded user experience. To avoid these situations, it is important to shut down your applications gracefully. In this article, we'll discuss why graceful shutdowns are important, how to handle them in Node.js applications, particularly in the context of Docker, and the potential issues that could arise if not handled correctly.
Before proceeding, you should have:
Basic knowledge of JavaScript and Node.js
Understanding of Express.js framework
Familiarity with Docker and its basic commands
A graceful shutdown involves carefully handling the shutdown signal, completing the in-progress tasks, closing the active connections, and then finally allowing the application to terminate. This ensures that the system resources are properly freed and that the application does not exit while it's in the middle of important tasks.
Handling shutdown signals in your applications allows you to manage resources properly, provide a better user experience, and help your system degrade more gracefully. Not handling these signals can lead to issues like data loss or corruption, incomplete transactions, resource leaks, and unexpected behavior.
In this section, we'll walk through the code required to listen for shutdown signals in a Node.js application and how to perform cleanup tasks before allowing the application to exit.
In Node.js, we can listen to process-level signals, such as SIGINT and SIGTERM. These signals are emitted when the process is requested to shut down, whether by manual user interruption (SIGINT from Ctrl+C) or system-level termination (SIGTERM from Docker or another process manager). To listen for these signals, we can use the process.on method and provide a callback function that will be executed when these signals are received.
process.on('SIGTERM', () => {
console.log('SIGTERM signal received.');
});
process.on('SIGINT', () => {
console.log('SIGINT signal received.');
});
Once a shutdown signal is received, it's important to perform necessary cleanup tasks to close any open resources, finish transactions, and prepare the application for a graceful exit. This may involve closing database connections, completing any in-progress writes to file systems, or other application-specific cleanup. This cleanup code should be placed inside the callback function provided to process.on.
process.on('SIGTERM', () => {
console.log('SIGTERM signal received.');
// Perform cleanup tasks here
});
process.on('SIGINT', () => {
console.log('SIGINT signal received.');
// Perform cleanup tasks here
});
Remember to handle asynchronous cleanup tasks correctly. If a cleanup task is asynchronous (like closing a database connection), you'll need to handle it with async/await or Promises to ensure it completes before the process exits.
After performing the necessary cleanup tasks, we must manually terminate the Node.js process by calling process.exit(). This signals to the system (or Docker) that our application has finished shutting down. We can provide an exit code to this method; a code of 0 indicates a successful exit, while any other number indicates an error occurred. Typically, if we've handled everything correctly in our cleanup, we'll want to exit with a code of 0.
process.on('SIGTERM', () => {
console.log('SIGTERM signal received.');
// Perform cleanup tasks here
process.exit(0);
});
process.on('SIGINT', () => {
console.log('SIGINT signal received.');
// Perform cleanup tasks here
process.exit(0);
});
Remember, the goal of all this is to allow your application to exit gracefully when it receives a shutdown signal. This helps reduce the risk of data corruption, loss of data, and other issues associated with an abrupt termination.
Express.js applications, in particular, have some unique considerations when it comes to graceful shutdowns. This section discusses how to handle shutdown signals in an Express.js application, including how to stop the server from accepting new connections and how to ensure all existing connections are closed before shutdown.
First, we need to create an Express.js application and start a server. Once the server is created, we can use it to close existing connections when we're ready to shut down the application.
import express from 'express';
const app = express();
const server = app.listen(3000, () => {
console.log('Server listening on port 3000');
});
Just like in a basic Node.js application, we need to listen for SIGINT and SIGTERM signals. We can use the process.on method to add listeners for these signals. Inside the callback function for each listener, we'll call server.close() to stop the server from accepting new connections and to begin the process of shutting down.
process.on('SIGTERM', () => {
console.log('SIGTERM signal received.');
server.close(() => {
console.log('Closed out remaining connections');
// Additional cleanup tasks go here
});
});
process.on('SIGINT', () => {
console.log('SIGINT signal received.');
server.close(() => {
console.log('Closed out remaining connections');
// Additional cleanup tasks go here
});
});
When server.close() is called, the server stops accepting new connections and waits for all existing connections to close. The function that we pass to server.close() will be called once all connections are closed. This is where we can perform any additional cleanup tasks that need to happen before the application shuts down.
Depending on the needs of your application, you may have additional cleanup tasks that need to happen when your application shuts down. For example, if you have a database connection, you should close it before your application exits. This cleanup code should be placed inside the callback function that you pass to server.close().
process.on('SIGTERM', () => {
console.log('SIGTERM signal received.');
server.close(() => {
console.log('Closed out remaining connections');
// Additional cleanup tasks go here, e.g., close database connection
process.exit(0);
});
});
process.on('SIGINT', () => {
console.log('SIGINT signal received.');
server.close(() => {
console.log('Closed out remaining connections');
// Additional cleanup tasks go here, e.g., close database connection
process.exit(0);
});
});
When running a Node.js application in a Docker container, there are additional considerations to take into account. This section discusses how Docker sends shutdown signals and how to ensure your Node.js application can handle them correctly.
When Docker is asked to stop a running container, it sends a SIGTERM signal to the main process running in the container. This is Docker's way of asking the process to shut down gracefully, by finishing what it's currently doing, cleaning up as needed, and then terminating.
However, if the process does not terminate within a certain period (10 seconds by default), Docker will then send a SIGKILL signal to forcibly terminate the process. This is akin to pulling the plug on the application - it won't have a chance to finish what it's doing or clean up.
This is why our Node.js application needs to listen for and handle the SIGTERM signal, as we discussed in previous sections. By handling SIGTERM, our application can ensure it shuts down gracefully when Docker asks it to stop.
Sometimes, our application may need more than 10 seconds to shut down gracefully. For example, it might need to finish processing a long-running request, or it might need to wait for a database transaction to commit.
In such cases, we can tell Docker to wait longer before it sends the SIGKILL signal, by using the --stop-timeout option when we run our Docker container. This option takes several seconds as its argument.
For example, to start a Docker container and give it 30 seconds to shut down gracefully before forcibly killing it, we would use a command like this:
docker run --stop-timeout 30 my-nodejs-app
Keep in mind that while extending the stop timeout can help in some situations, it's not a panacea. If your application consistently takes a long time to shut down, it may be a sign that it needs to be optimized or refactored.
Handling shutdown signals in your Node.js applications allows you to manage resources properly, reduce potential data loss or corruption, provide a better user experience, and more. By understanding how to handle these signals, you can make your applications more robust and reliable, both in development and in production.