Pm2: Python script executes the global rather than the specified interpreter virtual environment

Created on 18 Mar 2016  Â·  13Comments  Â·  Source: Unitech/pm2

Reference this stack overflow post.

When the file names ends in '.py', the pm2 start command ignores the 'interpreter' option. I was trying to execute a Python script on a particular virtual environment. My solution was to remove the '.py' extension and all works as intended, but I suspect that this would be considered a bug by the developers.

Machine details:
pm2 -v
1.0.2
node --version
v5.6.0
Ubuntu server on AWS, EC2

Most helpful comment

Anyone had a buffering problem when using PM2 with Python apps? On my machine it seems that Python application log does not get flushed, so I cannot use pm2 logs

The solution was to add the -u option to the Python interpreter:

apps:
  script: app.py
  interpreter: /usr/bin/python3
  interpreter_args: -u

All 13 comments

Seems answered in the stackoverflow, you have to specify the exec_interpreter.

FIY This is the list of supported interpreters by file extension :

https://github.com/Unitech/pm2/blob/76100dec1f00277fcc202a1e786d2e95366fdc57/lib/CLI/interpreter.json

(coffee will be removed soon).

I have done a work around which solved my problem. This is what the stackoverflow reference documents.

The issue was that if I have a file with a *.py extension, then the interpreter that I specified on the command line was completely ignored. I just wanted to make you aware of this potential. It doesn't seem like the sort of behavior that one would expect.

Are you saying that it overrides the exec_interpreter? If it's the case this is most likely a bug.

No, I am not using the 'exec_interpreter' option.

I am using the command-line option '--interpreter'.

pm2 start ./strain_to_db.py --interpreter /home/ubuntu/db_if/p3env/bin/python

If execute this script, the interpreter that I specified using the --interpreter option is completely ignored.

If I remove the *.py extension from the file, then it works as expected.

Ok in fact --interpreter is exec_interpreter in json so we're talking about the same thing, thanks.

Hmm I can't reproduce, I tried the same as you did:

pm2 start test/fixtures/binary-py3-file.py --interpreter /usr/bin/python3.4

And this works fine by replacing the interpreter with python3.4. I tried with a path, the binary and it works. I kept the .py extension too.
When doing pm2 desc 0:

│ interpreter       │ /usr/bin/python3.4                                        │

What about doing it from a virtual environment? Note that I specified an absolute path that was NOT the global path for my python environment.

I will investigate further and try to give more symptoms.

I cannot explain the discrepancy, but pm2 now appears to be functioning just as expected. I spent several hours on this a few days ago and I was convinced that this wasn't working correctly. You may close this issue. I am sorry to have taken your time with this.

Np, yes I tried an absolute path and a binary. Feel free to ping me if the problem persists.

Anyone had a buffering problem when using PM2 with Python apps? On my machine it seems that Python application log does not get flushed, so I cannot use pm2 logs

The solution was to add the -u option to the Python interpreter:

apps:
  script: app.py
  interpreter: /usr/bin/python3
  interpreter_args: -u

Can I specify interpreter_args options from command line ? It seems for me that I should generate ecosystem.config.js file and specify above option there.

I created a echosystem file echosystem.config.json

{
    "apps": [{
        "name": "app_name",
        "script": "/the/app/path/my_app.py",
        "args": ["-c", "my_config.prod.json"],
        "instances": "1",
        "wait_ready": true,
        "autorestart": false,
        "max_restarts": 5,
        "interpreter" : "/path/to/venv/bin/python",
    }]
}

Run the pm2 service:

$ pm2 start echosystem.config.json
$ pm2 -v
3.2.8
Was this page helpful?
0 / 5 - 0 ratings