Feature Request? Update Ecosystem & Files without immediately running them

[wmelton]

What's going wrong?

We manage a large number of batch jobs on various cron schedules using the PM2 Ecosystem file. However, if we deploy code changes to any one of the scripts, or add a new job, there is no mechanism to deploy the changes and reload/restart the ecosystem file without it running all of the jobs immediately.

We would prefer a mechanism where we can tell PM2 upon reload/restart via ecosystem file to not immediately run any of the scripts but wait until the next crontab schedule for that script in the ecosystem file to be met and then run.

This is super painful given some jobs are long running and scheduled to run only at night for that reason, but could get kicked off again and again if we are making many changes per day.

We know that the --only flag is available, but we do not want to run the script when the changes are made, we want to know that when the next crontab schedule is met that the changes will be picked up and run then.

How could we reproduce this issue?

Create several scripts with crontab schedules, then deploy any change to one of the files and use reload or restart on the ecosytem file after changing one of the crontab schedule settings.

All the scripts will immediately run.

Supporting information

In an ideal world, there would be a mechanism to update the ecosystem file or just the scripts or both and have a flag that would tell PM2 to not run on restart but to still wait until the next crontab scheduled run is met.

[wmelton]

Is this the purpose of the update CLI command? The docs say that it will "...update the in-memory PM2 daemon..." but I'm not sure if that means it will reread in the latest ecosystem and local files or not. Clarity or perhaps just better documentation on that command would be useful.

[wmelton]

@Unitech any thoughts here?

[wmelton]

@WillianAgostini is this already possible just not documented well?

[ultimate-tester]

Is this the purpose of the update CLI command? The docs say that it will "...update the in-memory PM2 daemon..." but I'm not sure if that means it will reread in the latest ecosystem and local files or not. Clarity or perhaps just better documentation on that command would be useful.

This would update the daemon in memory with a newer version if there's any (so let's say, if you did an upgrade of pm2). It shouldn't reread anything. If you want to reread your stored config, you could use pm2 resurrect. This is not an answer to the OP's question though.

@wmelton for me to understand your issue properly, do you mean to say that when you're using a --cron scheduled restart, an older version of your script is still used? Or is this limited to changes into the ecosystem file?

[wmelton]

@ultimate-tester the issue we have is that we have days where we schedule new batch jobs in our ecosystem file in the middle of the day, but do not want our nightly jobs to run as a result of updating it. However, there is no flag/mechanism to tell pm2 to reload/restart our ecosystem file (to see the new job additions/deletions) that does not run all of the jobs right then.

We would want a mechanism to tell pm2 that we have updated our ecosystem file but don't want it to run any scripts within the ecosystem file right then, but instead, wait until the next time the cron constraint is met.

This is a request that isn't new from my google searches, but there appears no way to satisfy this need that I have found in the documentation.

[ultimate-tester]

@wmelton thanks for clarifying, I get it now. It's true that right now there's no such feature because of two missing elements:

• The --cron parameter offers a restart strategy (i.e. when to restart) and not a start strategy (i.e. when to start the first time) OR just a parameter to not start initially.
• The command line for PM2 does not offer a way to reload the ecosystem file while maintaining the current state of all applications as they are.

I'd be happy to provide a PR for this, the first item should be easy to reuse the existing cron logic for starting an app instead and the second one would need a bit more fiddling but I'd feel comfortable enough to make this as long as I'm sure the PR will be accepted (to not waste my time/efforts).

[wmelton]

@ultimate-tester that would be amazing. I think a start strategy would go a long way in helping us deploy ecosystem changes without restarting all jobs right then when we make changes.

[ultimate-tester]

@wmelton alright so I don't have a full setup of pm2 available to me right now to do extensive testing, but I managed to make something out of it. Hopefully it will satisfy your requirements. It can be found at https://github.com/ultimate-tester/pm2/tree/5711.

What this does is introduce an autostart parameter (just like autorestart which already exists). Both to the ecosystem file and as argument to the start command. This means that you can either:

• Add autostart: false in your ecosystem file in the app object (apps: [{..., autostart: false,...}])
• Add --no-autostart argument to your pm2 start command (e.g. pm2 start app.js --no-autostart)

Both will result in an app to be added with status stopped.

If I understand your usecase the right way, this means you want to add autostart: false to all your apps that have a cron_restart parameter set. This means that the first start of new apps will be at that cron_restart moment.

Let me know if this works for you and I can request a merge request :)

[wmelton]

@ultimate-tester that is exactly what we're looking for 🎉 - Thank you for adding this. Will be awesome to see this merged in to the main trunk.

[wmelton]

@ultimate-tester would you be able to open a PR for this? Or is it possible for me to go ahead and open it?

[Unitech]

Feature landed

Update PM2 to 5.4.0

$ npm install pm2@5.4.0 -g
$ pm2 update