Deploy and run as different user.

[mozeryansky]

I have figured out how to run PM2 as another user, but it's not so simple. Basically I just created another user, su into that user, and run PM2 from there. I'm trying to accomplish what nginx and apache do when they run as root, but fork the processes as www-data. I don't see a way to change the user after forking.

I can do this automatically with a startup script. Since init.d is run with root privileges, it can easily change the user.

My problem comes when I also want to use deploy from the local machine. Deploy requires that the same user which ssh's is the one who runs PM2. I (like most) do not allow SSH from root. I was able to to configure my machine to allow my user to su into my "www-data" using /etc/PAM.d/su, but I have hit a road block with the way deploy was written: #2231.

Has another accomplished deploy and a startup script?
Should the related issue be fixed and my workarounds be how it's done?
Can I request that PM2 forks as another user with lower permissions?

[soyuka]

We removed --run-as-user because it was causing more problems then resolving this particular issue. Starting pm2 from the user that should run the script seems to me to be the best solution.

[soyuka]

We removed --run-as-user because it was causing more problems then resolving this particular issue. Starting pm2 from the user that should run the script seems to me to be the best solution.

[mozeryansky]

I did eventually find the issues that talked about that. I did come up with my own method, but I need #2231 to be fixed. Do you have any thoughts on that?

[mozeryansky]

I did eventually find the issues that talked about that. I did come up with my own method, but I need #2231 to be fixed. Do you have any thoughts on that?

[vmarchaud]

You can just execute PM2 with PM2_HOME env variable and pm2 will connect to the daemon at the path defined (you need to allow any another user to read the socket file to allow to communicate with the daemon)

[vmarchaud]

You can just execute PM2 with PM2_HOME env variable and pm2 will connect to the daemon at the path defined (you need to allow any another user to read the socket file to allow to communicate with the daemon)

[gkalpak]

Has the --user option replaced --run-as-user (for example in pm2 start --user someone /path/to/my/app)?
It doesn't seem to have any effect. --user seems to be ignored 😞

[gkalpak]

Has the --user option replaced --run-as-user (for example in pm2 start --user someone /path/to/my/app)?
It doesn't seem to have any effect. --user seems to be ignored 😞

[soyuka]

@gkalpak No you need to start the pm2 binary from that specific user. You could also play with process.setuid but I can not guarantee the outcome.

[soyuka]

@gkalpak No you need to start the pm2 binary from that specific user. You could also play with process.setuid but I can not guarantee the outcome.

[gkalpak]

OK, thx for the quick reply. Should the --user option be removed then (from the code and the docs)?

[gkalpak]

OK, thx for the quick reply. Should the --user option be removed then (from the code and the docs)?

[soyuka]

The --user option is only used by the startup command as far as I recall.

[soyuka]

The --user option is only used by the startup command as far as I recall.

[gkalpak]

Sorry. You are right!

[gkalpak]

Sorry. You are right!

[jmeit]

Is there any plan to reinstate the --run-as-user option?

[jmeit]

Is there any plan to reinstate the --run-as-user option?

[architech99]

@jmeit I was playing around with this because I needed a specific user to execute a process. They don't have the --run-as-user option, but there is the --uid option, which takes the same argument and works just fine.

[architech99]

@jmeit I was playing around with this because I needed a specific user to execute a process. They don't have the --run-as-user option, but there is the --uid option, which takes the same argument and works just fine.

[davidjb]

Following @architech99's suggestion worked for exec_mode: 'fork' processes, but fell apart for an app using exec_mode: 'cluster'; pm2 was being run as root, and using pm2 start ... --uid foobar to run the processes as the limited-access user foobar. The clustered processes would start but fail immediately, with no error logs seen in pm2 logs, just listed as errored in pm2 status. Removing my error_file option in ecosystem.config.js indicated that pm2 was attempting to write to /root/.pm2/logs/... and getting an access denied message, seemingly indicating the logs were attempting to be written by the limited-access user. That's as far as I went into that problem, but it seems that there's a degree of conflict with where logs are being written to and by whom.

Giving up on using --uid and switching to pm2 startup --user foobar --hp /home/foobar made my config work so that'll do for now. Ideally, a solution to the original problem @mozeryansky raised would be good so one root-level instance of pm2 can run with multiple sub-processes beneath it.

[davidjb]

Following @architech99's suggestion worked for exec_mode: 'fork' processes, but fell apart for an app using exec_mode: 'cluster'; pm2 was being run as root, and using pm2 start ... --uid foobar to run the processes as the limited-access user foobar. The clustered processes would start but fail immediately, with no error logs seen in pm2 logs, just listed as errored in pm2 status. Removing my error_file option in ecosystem.config.js indicated that pm2 was attempting to write to /root/.pm2/logs/... and getting an access denied message, seemingly indicating the logs were attempting to be written by the limited-access user. That's as far as I went into that problem, but it seems that there's a degree of conflict with where logs are being written to and by whom.

Giving up on using --uid and switching to pm2 startup --user foobar --hp /home/foobar made my config work so that'll do for now. Ideally, a solution to the original problem @mozeryansky raised would be good so one root-level instance of pm2 can run with multiple sub-processes beneath it.