I'm a bit of a novice with this so apologies if i'm not using this properly
pm2 failing to run processes
4|dashboar | 23-01 13:02:03.739: EPERM, Operation not permitted on call setuid
4|dashboar | 23-01 13:02:03.760: root is not accessible
Not sure atm, but the error messages above might be correlated with the change https://github.com/Unitech/pm2/pull/3404
This was caused with the v2.9.2 release
You need to run pm2 with root rights to be able to use --uid / --gid
Best,
I encounter a similar issue in my Vagrant development environment since today as well. I'm not using --uid / --gid functionality. Coincidentally, this question was also asked today on Stack Overflow: https://stackoverflow.com/questions/48404492/pm2-eperm-operation-not-permitted-on-call-initgroups#
EPERM, Operation not permitted on call initgroups
vagrant is not accessible
I suspect this is a regression in the 2.9.2 version of PM2 released yesterday.
I can confirm that reverting to 2.9.1 resolves this issue.
Do you run commands with sudo?
[email protected] published with hotfix
Could you try again?
Also could you give me steps to reproduce the issue, thank you
Thanks, running now, deploy takes 20 minutes... yawn
Thanks alot @Unitech I think that's resolved it.
Do you run commands with sudo?
It's debian so, pm2 was installed under root, and then with su myuser (via ansible "become: myuser") the command pm2 start -u myuser ... was run.
FYI: if i were to do this above manually it would work, so possibly CI or ansible defines SUDO_USER irrespective of the become: myuser setting.
have the same problem, amazon linux, same pm2 2.9.2, I don't think 2.9.3 solves the issue, still investigating
done clean test for versions 2.9.1, 2.9.2, 2.9.3
2.9.1 - no issue
2.9.2 - I see the problem
2.9.3 - no issue
2.9.3 resolves the problem for me
We removed code which leads to the issue on 2.9.3.
Everything seems fine now.
$ npm install pm2 -g
$ pm2 update
Most helpful comment
Thanks alot @Unitech I think that's resolved it.
It's debian so, pm2 was installed under root, and then with
su myuser(via ansible "become: myuser") the commandpm2 start -u myuser ...was run.FYI: if i were to do this above manually it would work, so possibly CI or ansible defines SUDO_USER irrespective of the
become: myusersetting.