Pm2: PM2 change my CWD?

[hfcorriez]

I had some script writen in "./bin" dir not in root dir.

when I start using "pm2 start bin/app.js", I found my application will not found some directories.

PM2 change my current working directory? I think it's not sensible.

[ruquay]

This problem is preventing me from moving to pm2 as well. This creates a conflict with node-config, which expects to find the configuration directory in the current working directory.

[hfcorriez]

@ruquay Sure, I am using node-config for a long time, I can not replace it to other config manager!

[Unitech]

if you do pm2 start bin/app.js you try to get files into the folder bin/config.js for example ? By requiring it like require('./config.js') but it doesnt find this one ?

https://github.com/lorenwest/node-config/blob/master/lib/config.js#L107

[soyuka]

You could use global variables and base it on the app.js __dirname !

[ruquay]

Checking out the docs for node-config in more detail, it would be very possible, at least for me, to use the NODE_CONFIG_DIR environment variable.

[Unitech]

Ok I fixed the problem, I was doing a process.chdir(), I published the last version on npm (0.5.8)

$ npm install -g pm2@latest

[bevacqua]

@Unitech I'm still seeing this issue. I have a method like this, which pm2 breaks by breaking process.cwd()

global.require_cwd = function(file){
    var absolute = path.join(process.cwd(), file);
    return require(absolute);
};

[bevacqua]

In fact, your "fix" broke my code because it relied on cwd being the root directory for my project, not wherever pm2 is. Using npm install [email protected] works, however.

[bevacqua]

I think you should at least provide an option to use the legacy behavior, as that even feels more natural (generally packages use spawn, or exec, without losing cwd context)

[Unitech]

ok i replicate the same bahaviour than node executable. Can you try (branch master) an tell me if everything is okay now ?
Thanks

[erelsgl]

I think the best solution is to add, to the "start" command, a parameter "start from folder". The process will be started like this:
cd [start-from-folder]
node [process-name] [process-args]

This is the common practice, for example, in Windows links.

[bevacqua]

How about a --prefix, like in npm?
On Oct 3, 2013 8:38 AM, "Erel Segal-Halevi" [email protected]
wrote:

I think the best solution is to add, to the "start" command, a parameter
"start from folder". The process will be started like this:
cd
node

This is the common practice, for example, in Windows links.

—
Reply to this email directly or view it on GitHubhttps://github.com/Unitech/pm2/issues/96#issuecomment-25613345
.

[Unitech]

The new version of pm2 (available soon) will integrate the exactly same behaviour than node

[gausie]

This is still a problem for me!

[gianmarcotoso]

This is definitely still an open issue. PM2 changes the cwd to the home directory of the user that is running the app instead of keeping the path of where the app is actually running.

I am using the latest version, of course.

[Rush]

I am finding this issue as well as a new user of pm2. I thought it would actually work better then forever...

[adamshiervani]

Same as @RushPL. Is there any workarounds yet?

[EvanCarroll]

Is this ever going to get addressed? Is there a doc on this?

[gianmarcotoso]

I found that if you pm2 start the node application from within its CWD it works perfectly. I haven't had this issue in a while, and the CWD persists throughout multiple reboots if you are using the startup script as well.
Just don't do
pm2 start /var/www/node/myapp/myapp.js
but do
cd /var/www/node/myapp; pm2 start myapp.js

[EvanCarroll]

right, but what if you have multiple apps you run under cluster, and you use a pm2 config file?

[soyuka]

I never had this issue either, even if I'm starting my script from any folder. The main reason is that I prefer the use of __dirname for my app root directory instead of process.cwd which is the current working directory that might change according to what your application might do...

There are a lots of workaround here so pm2 isn't the one to blame...

[Downchuck]

This is difficult to find, while the @soyuka method of using __dirname is the most rugged for source code, many projects are more likely to use relative folders and the cost of adjusting them is prohibitive.

[soyuka]

You can change the cwd through the json declaration: https://github.com/Unitech/PM2/blob/master/ADVANCED_README.md#list-of-all-json-declaration-fields-avaibles

[Downchuck]

@soyuka well aware of that, but I am not currently using JSON declarations.

[Downchuck]

pm2 start --json '....' would have been nice, as I work through these subtleties.

[soyuka]

Just start from the cwd you want: cd my/path && pm2 start app.js

[Downchuck]

@soyuka yes I'm aware of that; it's a workaround.. cd my/path.. BIGSETOF_ENV pm2.. cd $OLDPWD... it's clutter in what would've been quicker and easier.

[soyuka]

@Downchuck I'm sorry but there is no such feature. Why don't you set a json declaration? You can put your env variables in it too!

[thetoxicavenger]

Glad I found this thread. Phew.

[knoxcard]

should be something like pm2 start myapp.js --homedir=/myhomdir/

[knoxcard]

Interesting! I got my apps to work by including the full path...
pm2 startup "/my/direct/path/node_app.js"

Make sure to delete all your existing services and include the full path to your app. DO NOT just go to your directory and pm2 add node_app.js.

UPDATE
I no longer have to include the full path to start up my scripts with PM2. Appears to be completely fixed at this point.

[lifehome]

So what's the solution to this? Other than cd /path/to/dir and pm2 start myscript?

[nikhilnxvverma1]

I tried the CWD option in my ecosystem.config.js. It is still not working. I am trying to run pm2 one level above my project directory.

[nikhilnxvverma1]

Got it! Turns out I was changing my ecosystem file but still using the same configuration. I had to kill the app(i.e. downtime) and then start the service again
pm2 kill
pm2 start ecosystem.conf.js

NOTE: I tried pm2 reload ecosystem.conf.js for zero downtime, but that did not work for "CWD" field.

[inl-pd-autotest]

This issue shouldn't have been closed without a fix.

[Bastorx]

If you use a process.yml rename it to process.config.js
http://pm2.keymetrics.io/docs/usage/application-declaration/

const path = require("path");
module.exports = {
   script: path.resolve(__dirname, "path/to/app.js"),
};

[inl-pd-autotest]

Thanks, but I started things manually and later figured out that there are --cwd and --hp.

[chriszrc]

I couldn't get this to work, I just added a environment specific prefix to places where __dirname was used:

middleware(path.join(process.env.SWAGGER_DIR_NAME + __dirname, 'Api.yaml'), app, function(err, middleware) {

[leodutra]

I had to set every app script with:

cwd: `${__dirname}`

Worked.

[leonardlepadatu]

I have a similar issue:
I had to install pm2 locally but not global:

npm install pm2 -s

Now I had to use pm2-logrotate from keymetrics:

myProject/node_modules/.bin/pm2 install pm2-logrotate

This installed pm2-logrotate in ~/.pm2/modules

$ myProject/node_modules/.bin/pm2 describe pm2-logrotate

name              │ pm2-logrotate
script path      │ /home/user/.pm2/modules/pm2-logrotate/node_modules/pm2-logrotate/app.js
exec cwd        │ /home/user/.pm2/modules/pm2-logrotate/node_modules/pm2-logrotate 

There is a way to change script path and exec cwd for this module?

Thank you!

[Unitech]

@leonardlepadatu this would require some changes there https://github.com/Unitech/pm2/blob/master/lib/API/Modules/Modularizer.js#L54

PR welcome

[leonardlepadatu]

@Unitech, I think I find a way(hack) more easy to do that, but I don't know if it works :) I will test it right now.

1. On ReplicaServer(with Internet access) install pm2-logrotate as usual:
   $ myProject/node_modules/.bin/pm2 install pm2-logrotate
   This will install the module in /home/user/.pm2
2. Change environment.config.js like:

...
        env: {
            ...
            PM2_HOME: '/myProject/.pm2'
        },
...

1. mkdir /myProject/.pm2 && cp -R ~/.pm2/* /myProject/.pm2
2. start pm2 with: $ /myProject/node_modules/.bin/pm2 start /myProject/environment.config.js --update-env
3. If working, I will just tar gz all project and delivery to ClientServer

...as you obviously realize, the ClientServer have white list firewall;

I will let you know if it works ...

P.S. Regarding PRs I will be glad to help, but not right now (this project kill all my free 'slots' :)) ). But very soon ...

[Unitech]

Nice hack, but not very repeatable) I think changing some path in pm2 source code will do the job)

[jbcpollak]

We are having this problem - we use nodenv with .node-version files to specify which version of node we want per-project.

We then try and start a few applications with pm2 programmatically:

    const conf = {
        name,
        cwd,
        script: 'npm',
        args: ['start'],
        interpreter: 'none', // will execute the ‘script’ as a binary executable
    };

        pm2.start(conf, (err, proc) => {
        if (!!err) reject(err);
        resolve(proc);
        });

when I run this, I find the process started with the node version of the pm2 instance, rather than the configured version in the project's directory.

This is puzzling because when I tried this launch config:

    const conf = {
        name,
        cwd,
        script: 'pwd',
        interpreter: 'none', // will execute the ‘script’ as a binary executable
    };

I do see the expected path (the value of cwd).

However, I confirmed that nodenv wasn't picking up the correct version by:

    const conf = {
        name,
        cwd,
        script: 'nodenv',
        args: ['version'],
        interpreter: 'none', // will execute the ‘script’ as a binary executable
    };

This will emit the node version of our process-starting application, not the version configured via cwd.

[stiv-yakovenko]

So the problem is still not addressed?

[bernardopacheco]

On my case, I was running PM2 with Express and __dirname was always / no matter what. After some hours debugging, I noticed it wasn't a PM2 issue, but a Webpack issue since my web app is processed by Webpack. The solution was to add this to the webpack.config.js to fix the __dirname resolution:

// the webpack config just works
target: 'node',
node: {
  __dirname: false,
  __filename: false,
}

I've grabbed the solution from here: https://github.com/webpack/webpack/issues/1599#issuecomment-186841345

I hope it helps.