Wrong PID for process, application not stopped on FreeBSD
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 43.3k
- Forks
- 2.7k
- PR merge metrics
- No merged PRs in 30d
Description
What's going wrong?
The problem occurs when running PM2 on FreeBSD. Testing on Ubuntu latest LTS doesn't have that issue.
When you start an application via PM2, either directly or using an ecosystem config file, PM2 launches two processes. One is what can be called the "start" process and the other is the application process itself. The PID reported in the PM2 daemon is for the "start" process.
When you want to close the application, PM2 stops the "start" process and leaves the application itself running.
This may not be a problem of PM2, but rather the fact that FreeBSD or node on FreeBSD works a bit differently and it hasn't been taken into account. Any opinions or information is welcome.
On Ubuntu we can see in the 'ps' output that the processes have a parent&child relation. This doesn't seem to be the case on FreeBSD where both processes in the 'ps' output are listed as separate processes.
Here we have PM2 running and we are starting 'strapi' application. The PID for the application is reported as 1200.
pm2@pm2test:~ $ pm2 --trace start strapi
[PM2] Applying action restartProcessId on app [strapi](ids: [ 2 ])
[PM2] [strapi](2) ✓
[PM2] Process successfully started
┌────┬───────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │
├────┼───────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 1 │ hello │ default │ N/A │ fork │ 0 │ 0 │ 0 │ stopped │ 0% │ 0b │ pm2 │ disabled │
│ 2 │ strapi │ default │ N/A │ fork │ 1200 │ 0s │ 3 │ online │ 0% │ 44.7mb │ pm2 │ disabled │
└────┴───────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
[PM2][WARN] Current process list is not synchronized with saved list. Type 'pm2 save' to synchronize.
When checking the 'ps' output, we can see two processes. PID 1200 is for the 'start' process and the application itself is running under PID 1202.
pm2@pm2test:~ $ ps auxf |grep node
pm2 1202 103.7 11.2 919152 230144 - S 16:31 0:03.01 node /usr/home/pm2/my-project/node_modules/.bin/strapi start
pm2 1200 3.0 4.1 700340 84152 - Ss 16:31 0:00.68 node: npm start (node)
pm2 845 0.0 3.1 674224 63744 - Ss 15:30 0:01.92 node: PM2 v5.3.0: God Daemon (/home/pm2/.pm2) (node)
pm2 1206 0.0 0.1 12812 2360 0 S+ 16:31 0:00.00 grep node
Now we stop the application, the Strapi application is stopped and it has no PID anymore.
pm2@pm2test:~ $ pm2 --trace stop strapi
[PM2] Applying action stopProcessId on app [strapi](ids: [ 2 ])
[PM2] [strapi](2) ✓
┌────┬───────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │
├────┼───────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 1 │ hello │ default │ N/A │ fork │ 0 │ 0 │ 0 │ stopped │ 0% │ 0b │ pm2 │ disabled │
│ 2 │ ☵ strapi │ default │ N/A │ fork │ 0 │ 0 │ 3 │ stopped │ 0% │ 0b │ pm2 │ disabled │
└────┴───────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
[PM2][WARN] Current process list is not synchronized with saved list. Type 'pm2 save' to synchronize.
When checking the 'ps' output, we see that the application with PID 1202 is still running.
pm2@pm2test:~ $ ps auxf |grep node
pm2 1202 3.0 9.7 891504 199924 - S 16:31 0:03.50 node /usr/home/pm2/my-project/node_modules/.bin/strapi start
pm2 845 0.0 3.2 676784 64812 - Ss 15:30 0:01.98 node: PM2 v5.3.0: God Daemon (/home/pm2/.pm2) (node)
pm2 1213 0.0 0.1 12812 2360 0 S+ 16:32 0:00.00 grep node
PM2 log shows the following:
pm2@pm2test:~ $ tail -f /home/pm2/.pm2/pm2.log
2023-11-07T16:32:03: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: pid=1200 msg=failed to kill - retrying in 100ms
2023-11-07T16:32:04: PM2 log: Process with pid 1200 still alive after 1600ms, sending it SIGKILL now...
2023-11-07T16:32:04: PM2 log: App [strapi:2] exited with code [0] via signal [SIGKILL]
2023-11-07T16:32:04: PM2 log: pid=1200 msg=process killed
How could we reproduce this issue?
Installation & setup:
FreeBSD 13.1/13.2/14.0 vanilla installation
pkg install node20-20.8.1
pkg install npm
pkg install pm2@latest -g
Add a non root user and start PM2 for it (https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-22-04#step-2-installing-pm2)
define PM2_HOME environment variable for the user
Install packages to run Strapi (https://strapi.io/) as the test application
pkg install -y pkgconf vips
npm install -g npx
Create a Strapi application
npx create-strapi-app@latest my-project
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the behavior on a vanilla FreeBSD 13.1/13.2/14.0 setup using Node 20, PM2, and the Strapi commands described in the issue. Compare PM2's reported PID and stop behavior with the two processes shown by ps; done means PM2 reports and stops the actual application process rather than leaving it running.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, nodejs
- Domain
- cli, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100