CodingNic

Process Management & Reliability

Exercises

Process Management & Reliability 25 min read

Exercises

Objectives

By the end of this lesson, you should be able to:

  • Run an application under PM2, and confirm it restarts automatically after a crash
  • Read PM2’s status output to understand a running application’s health
  • Explain when PM2 alone is enough, and when the cluster module still matters

⚠️ A note on verification: every command and every output in this lesson was actually run.

Exercise: Automatic Restarts with PM2

a) Install PM2:

bash
npm install pm2

b) A server that crashes on purpose, simulating the exact kind of bug Lesson 1 covered:

javascript
// flaky.js
const express = require('express');
const app = express();
app.get('/', (req, res) => res.json({ pid: process.pid }));
app.listen(6002, () => console.log(`Flaky server ${process.pid} started`));

setTimeout(() => {
  console.log(`Server ${process.pid} crashing on purpose`);
  process.exit(1);
}, 500);

c) Start it under PM2, instead of running it directly with node:

bash
npx pm2 start flaky.js --name flaky-app

d) Check its status after it’s had time to crash and restart a few times:

text
│ id │ name         │ mode    │ pid  │ uptime │ ↺  │ status  │
│ 0  │ flaky-app    │ fork    │ 70   │ 0s     │ 3  │ online  │

status              online
restarts            3
unstable restarts   3

↺ (and restarts in the detailed view) is PM2’s restart counter, 3 here means the process crashed and was automatically restarted three times, and status: online confirms it’s currently running, despite every one of those crashes, no person needed to notice the crash and restart it manually, PM2 did, within a fraction of a second each time.

e) Clean up:

bash
npx pm2 delete flaky-app

PM2 vs the Cluster Module

They solve related but distinct problems: PM2 restarts a crashed process, whether there’s one instance or many, the cluster module runs multiple instances in the first place, using more than one CPU core. In practice, they’re often used together, PM2 can itself run an application in cluster mode (pm2 start app.js -i max, using Node’s cluster module under the hood), giving both automatic restarts and multi-core usage from one tool, without hand-rolling the primary/worker code from Lesson 2 directly.

Try It

  1. Build flaky.js, run it under PM2, and confirm the restart count increases over time using pm2 list or pm2 describe.
  2. Run pm2 logs flaky-app (or check pm2 describe’s log file paths) while it’s crashing repeatedly, and confirm the crash message appears in the logs each time.
  3. Try pm2 start app.js -i max on a non-crashing server, and compare its output to the hand-rolled cluster module code from Lesson 2, how many workers does it start, and how is that number chosen.
  4. Explain, in one or two sentences, a scenario where PM2’s automatic restarts alone (no cluster mode) would already be enough, without needing multiple instances.

Recap

This module replaced a single, fragile node server.js process with a real, production-shaped setup: understanding exactly how a single uncaught exception can take an entire server down, Node’s cluster module for running multiple, independent workers across CPU cores, graceful shutdown so routine deploys don’t drop in-flight requests, and PM2 tying it together, restarting a crashed process automatically, confirmed here with a real, repeatedly-crashing process that PM2 kept bringing back online.

Next module: containerizing this application with Docker, so it runs identically wherever it’s deployed.