Keywords: PM2 | Process Management | Node.js | Daemon Process | Process Termination
Abstract: This technical paper provides an in-depth analysis of terminating PM2 processes running in --no-daemon mode. It examines PM2's process management architecture, details the implementation of pm2 kill command, explains process signal handling mechanisms, and presents alternative system-level termination approaches. Through comprehensive code examples and practical insights, the paper offers a complete solution spectrum from graceful shutdown to forced termination, empowering developers to effectively manage PM2 processes in local debugging environments.
Understanding PM2 Non-Daemon Process Termination
In Node.js application development, PM2 serves as a robust process manager typically operating in daemon mode to ensure application high availability. However, during local development and debugging sessions, developers frequently employ the --no-daemon option to launch PM2, enabling real-time log monitoring and process state observation. The proper termination methodology under this configuration presents a significant technical consideration.
Core Functionality of PM2 Kill Command
PM2 incorporates a dedicated termination command pm2 kill, specifically designed to comprehensively shut down all PM2-associated processes. When operating in non-daemon mode, executing this command will:
// Terminate PM2 and all managed processes
$ pm2 kill
[PM2] Applying action deleteProcessId on app [all] (ids: all)
[PM2] [all] processes successfully deleted
[PM2] All processes have been stopped and deleted
[PM2] PM2 daemon has been shut downThis command's primary advantage lies in its comprehensiveness—it not only halts currently running application processes but also cleans up PM2 daemon instances, ensuring complete system resource liberation.
Process Signal Handling Mechanism
Within Unix/Linux systems, process termination involves sophisticated signal handling mechanisms. PM2's termination process实质上achieves its objective by dispatching specific signals to target processes:
// Default SIGINT signal (interrupt)
$ kill -2 <pid>
// Forceful termination SIGKILL signal
$ kill -9 <pid>The SIGINT signal (signal number 2) permits processes to execute cleanup operations, such as closing file descriptors and preserving state information, facilitating graceful exit. Conversely, the SIGKILL signal (signal number 9) immediately terminates processes without permitting any cleanup. Within PM2's context, the pm2 kill command internally employs the SIGTERM signal, providing processes with adequate cleanup time.
System-Level Process Identification and Termination
When PM2 commands malfunction due to various reasons, developers can resort to system utilities for direct process manipulation:
// Identify all PM2-related processes
$ ps aux | grep PM2
user 1234 0.0 0.1 245672 12345 pts/0 Sl+ 10:30 0:00 PM2 v5.0.0: God Daemon
user 1235 0.1 0.2 345678 23456 pts/0 Sl+ 10:30 0:01 node /path/to/app.js
// Gracefully terminate PM2 daemon process
$ kill 1234
// Force termination (when graceful termination fails)
$ kill -9 1234While this approach offers direct control, it necessitates precise target process identification to avoid accidental termination of critical processes. Particularly in multi-user environments, as referenced in supplementary materials, conflicting PM2 instances across different users underscore the importance of accurate process recognition.
Process State Management and Recovery
PM2's process management extends beyond termination operations to encompass comprehensive state maintenance mechanisms. When utilizing --no-daemon mode, PM2 maintains process states within the current terminal session:
// Examine current PM2-managed process states
$ pm2 list
┌─────────┬────┬─────────┬──────┬────────┬─────────┬────────┬─────┬───────────┬──────────┐
│ App name│ id │ version │ mode │ pid │ status │ restart│ uptime│ memory │ watching │
├─────────┼────┼─────────┼──────┼────────┼─────────┼────────┼─────┼───────────┼──────────┤
│ app │ 0 │ 1.0.0 │ fork │ 1235 │ online │ 0 │ 5m │ 45.2 MB │ disabled │
└─────────┴────┴─────────┴──────┴────────┴─────────┴────────┴─────┴───────────┴──────────┘This state management capability enables developers to accurately comprehend current runtime environments, informing subsequent termination decisions.
Practical Recommendations and Best Practices
Based on empirical development experience, we advocate for a layered termination strategy: initially attempt the pm2 kill command, resorting to system-level termination commands only when processes become unresponsive. Concurrently, regular cleanup of PM2 log files and state information prevents resource accumulation issues. In team development environments, establishing unified process management protocols helps mitigate problems arising from process conflicts.