Unitech / Unitech/pm2

pm2 list should list process waited to be killed

Open
#5,245 0 comments 1 reaction 0 assignees View on GitHub

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?

For any app with long running or critical connections (like SMTP, or FTP) , you don't want to kill them. You want to wait the connection end. the kill_timeoutoption is done for it.

However there is no way to know if a process is still running after a pm2 reload, unless you look in the logs, where there will be al lot of lines like PM2 | pid=31416 msg=failed to kill - retrying in 100ms

How could we reproduce this issue?

ecosystem.config.js

module.exports = {
  apps: [{
    name   : "app",
    script : "./index.js",
    kill_timeout: 60*60*1000,
    kill_retry_time: 60,
    exec_mode: "cluster",
  }]
}

index.js

console.log('start');
process.on('SIGINT', () => {
  console.log('got SIGKILL');
})

var i = setInterval(() => {
  // just keep it alive
}, 1000)

Then run:

pm2 start app
pm2 reload app

You end with one unkilled process everytime you reload, but you don't know it unless you look at pm2 logs.

Supporting information

Nothing is handled for these process waited to be kill. Their pid is just trapped in a setIntervel.

I think these process IDs should at least be outputed in pm2 jlist (and also in the pm2.list())

With it , it easy to get these pids to send them messages, and do whatever it needs to end them properly.

Final step is to see them in the pm2 list, maybe as a new column like ghost pids, or probably something better :)

Thanks

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked location in lib/God/Methods.js, then trace how pm2 reload handles processes waiting to be killed and how pm2 jlist, pm2.list(), and pm2 list obtain process data. Done means the relevant PIDs are exposed through the JSON and list interfaces, including a clear representation in pm2 list.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, node.js
Domain
backend, cli
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.