-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process.argv behaves differently for pm2-runtime + cluster mode without pm2 daemon running #4950
Comments
Another data point on this...nextjs crashes due to: when running nextjs via pm2 (pm2 5.2.2, node 16.15) also fails on ubuntu 20.04 LTS. app.pm2.json{
"name" : "app_name",
"script" : "/opt/app_dir/node_modules/next/dist/bin/next",
"args" : "start",
"instances" : "1",
"exec_mode" : "cluster",
"cwd" : "/opt/app_dir",
"out_file" : "/dev/null",
"error_file" : "/dev/null",
"wait_ready" : false,
"listen_timeout" : 5000,
"kill_timeout" : 30000,
"max_restarts" : 1000000,
"restart_delay" : 100,
"max_memory_restart" : "1G",
"watch" : false
} Run with:
We are running the above and setting up the environment via a provisioned systemd service unit which is why we run with Added a
As far as I can tell, this issue will break any node apps that rely on |
I thought I had solved it from some combination of setting additional env. But it was a just a coincidence. It doesn't look like environment variables has anything to do with this. If I run According to the docs, args shouldn't be passed through to the script being run by pm2 unless they follow a |
Okay, so the problem is that the worker process is launched differently depending on whether a running daemon is detected running. The docs even hint at this:
They mean kill any running Daemon (the "God" process). Running almost any pm2 command (like case: pre-existing Daemon ("God" process)Basically, when the In this case the existing daemon process will field the RPC and does a case: no Daemon foundIn this case we hit the no-daemon init code. If you have If you are not using clustered multi-instance mode, then see ForkMode which uses The The thing to note here from the docs for
patching...You can just set the default for the worker If you are using the "Variadic" ( cluster.settings.args = []; // don't pass child args (any args from your pm2 json environment will get passed) Or when cluster.setupMaster({
windowsHide: true,
exec : path.resolve(path.dirname(module.filename), 'ProcessContainer.js'),
args: []
}); |
argv is now populated correctly when running in no-daemon mode.
Hi I'm also facing this issue. I'm using pm2-runtime to start next.js server. I'm using pm2-runtime v5.2.0. My config file is the following: #app.yml
apps:
- script: next
args: start I debug the
But if I run
next.js searches command from |
@chalermpong -- the open PR fixes this at least for no-daemon mode. You can take my PR and make your own build, fix it yourself, or move away from using pm2. We are doing the latter because of a variety of issues running pm2 in a serious devops environment. It is great for developers that want to get a node app into "production" without knowing anything about running servers. If you ask pm2 to just be a node process load balancer behind systemd without a global "god" process (daemon mode), then things seem to start falling apart. I'm guessing this is because the Unitech folks really don't test these edge cases very well because that isn't how they expect pm2 to be used by most folks. We often have 5-10 different pm2 users/apps on a single box. Every app gets own user/home-dir/etc because there isn't any reason to give them all the same permissions and access to each others' data. Our developers/devops never interact with pm2 directly because they would likely accidentally try to run pm2 as their own user rather than the correct pm2 user for that particular app (permissions problems, missing ENV set by systemd, etc). Rather developers are limited to For an alternative: you can run multiple instances of a single systemd service using an index number and having that index number passed into the unit file for instance to set/increment ports. Of course that only gets you so far, you also need a notion of health checks for your app, adding and removing individual app instances to a load balancer based on health checks, incremental rollout and validation of app deployments. However these topics are all quite individual to the app you are building and your devops tooling: what load balancer you use (LVS, HAProxy, nginx, ELB, hardware, etc), how you validate your apps health before passing more traffic. For us pm2 is just doing the node process load balancing (e.g. I have 2 cores and want 2 instances of the app running in round robin or with percentages of traffic). Doing deploys from CI assets, updating load balancer configs and doing health checks is just a small amount of scripting specific to your devops tools and nature of your apps. Good luck. |
What's going wrong?
execute
pm2-runtime start process.json
without a running pm2 daemon,"start", "process.json"
is included in applicationprocess.argv
.How could we reproduce this issue?
app.js
with contents below:process.json
with:pm2-runtime start process.json
, it logs something like:pm2 ps && pm2-runtime start process.json
and it logs something like:pm2 ps
is just for spawning the daemon process.Supporting information
pm2
,pm2-runtime
+fork
mode both works fine, it just thepm2-runtime
.The text was updated successfully, but these errors were encountered: