9

I'm running into some trouble with deploying Django on the passenger_wsgi module with virtualenv. The Python code in the passenger_wsgi.py file, which should fix my problem is:

import os, sys
INTERP = '/home/login/.virtualenvs/env_name/bin/python'
if sys.executable != INTERP:
    os.execl(INTERP, INTERP, *sys.argv)

The first three lines I understand, but I only have a very vague idea about the fourth one and that's the one that happens to be giving me an error:

/home/login/.virtualenvs/env_name/bin/python: can't find '__main__.py' in ''

So what is os.execl doing here exactly? And what does that error message mean?

codeforester
  • 39,467
  • 16
  • 112
  • 140
Monika Sulik
  • 16,498
  • 15
  • 50
  • 52

3 Answers3

8

It's not my intention to mess up with a question 9 years old, I googled "Python execl example" shortly and bumped into this thread, almost got misled by the answer, so I'm posting in hope of helping other visitors.

I agree with https://stackoverflow.com/users/479633/mouad about the way to reproduce the bug, but not the reason, the error occurs because when a python interpreter is opened interactively, sys.argv will be [''], so an empty string is passed to the execl-invoked python interpreter as the path to the main script (directory), since the main script file __main__.py cannot be found in directory '' (the current work directory), it complains about:

can't find '__main__.py' in ''

I can not figure out how https://stackoverflow.com/users/211075/monika-sulik managed to run a python script while successfully set the first member of sys.argv to '', it's my pure guess that the code got copy-pasted to the REPL.

As https://stackoverflow.com/users/845210/bjmc mentioned in Python: os.execl() - what does it do exactly? Why am I getting this error?, the documentation is correct, it's OK to pass the interpreter path twice, although not required the second time. The signature of the function has its root in the UNIX execve() API (https://linux.die.net/man/2/execve), which says:

argv is an array of argument strings passed to the new program. By convention, the first of these strings should contain the filename associated with the file being executed.

There are programs taking advantage of this inconsistency, e.g. busybox.

$ ln -s /bin/busybox cat
$ ./cat /etc/timezone
/UTC
$ python -c "import os; os.execl('./cat', 'cat', '/etc/timezone')"
/UTC
$ python -c "import os; os.execl('./cat', 'ls', '/etc/timezone')"
/etc/timezone

The inconsistency between the executable path and the argv[0] in main() has made getting the reliable path to the running python executable very hard (if not impossible) in a UNIX-like environment, here is a script to illustrate this:

import os
import sys


if len(sys.argv) >= 2 and sys.argv[1] == 'exec':
    os.execl('/usr/bin/python', 'ls', sys.argv[0])
else:
    print(sys.executable)
    print(sys.version)
    print(sys.argv)

Run this script

$ python test.py exec
/bin/ls
2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516]
['test.py']

and sys.executable has value "/bin/ls", as the documentation (https://docs.python.org/3/library/sys.html#sys.executable) says

A string giving the absolute path of the executable binary for the Python interpreter, on systems where this makes sense.

about sys.executable, if the python developers cannot figure out how to get sys.executable point to the path of the running python executable, it probably does not make sense in a UNIX-like environment. I would be grateful if someone tells me otherwise.

Roy Scheffers
  • 3,832
  • 11
  • 31
  • 36
coinfaces
  • 199
  • 2
  • 7
6

maybe you should do it like this:

os.execl(INTERP, *sys.argv) # don't pass again the interpreter path. 

i think this doc is wrong : http://wiki.dreamhost.com/Passenger_WSGI

about exec:

The exec functions of Unix-like operating systems are a collection of functions that causes the running process to be completely replaced by the program passed as an argument to the function.

os.execl(path, arg0, arg1, ...)
os.execle(path, arg0, arg1, ..., env)
os.execlp(file, arg0, arg1, ...)
os.execlpe(file, arg0, arg1, ..., env)
os.execv(path, args)
os.execve(path, args, env)
os.execvp(file, args)
os.execvpe(file, args, env)

from : http://docs.python.org/library/os.html

The “l” and “v” variants of the exec*() functions differ in how command-line arguments are passed. The “l” variants are perhaps the easiest to work with if the number of parameters is fixed when the code is written; the individual parameters simply become additional parameters to the execl*() functions. The “v” variants are good when the number of parameters is variable, with the arguments being passed in a list or tuple as the args parameter. In either case, the arguments to the child process should start with the name of the command being run, but this is not enforced.

Edit:

i just did what you were doing in a python shell and i get the same error:

>>> import os
>>> import sys
>>> os.execl('/home/login/projects/virtual/bin/python', '/home/login/projects/virtual/bin/python', *sys.argv)
/home/login/projects/virtual/bin/python: can't find '__main__.py' in ''
mouad
  • 67,571
  • 18
  • 114
  • 106
  • Thanks... I read that bit of the docs and didn't quite get it either though. Passing the INTERP argument once gets rid of the error, but not of the problem. Although it did help me to understand what exactly is happening ;-P The problem is that when INTERP is passed just once, the python process does seem to be replaced, but when I print sys.executable in the new process it's still says '/usr/bin/python', which is obviously not what I want. – Monika Sulik Oct 26 '10 at 16:21
  • Yep, that's how I'm debugging it - in the shell... no errors appear in the error.log (apparently passenger is very difficult to debug because the error logging sucks). And as django isn't working when there are errors in passenger_wsgi.py I don't get any errors sent via e-mail either. – Monika Sulik Oct 26 '10 at 16:25
  • Right... I've voted your answer up because experimenting with os.execl(INTERP, *sys.argv) is the best lead I have at the moment. The interesting thing is that it seems that when I do that, it doesn't actually change sys.executable to whatever I have in INTERP (which I'm assuming is the point?), but always changes it to '/usr/bin/python'. So even if INTERP = '/usr/bin/python2.7' rather than the path to the virtualenv, running that command makes sys.executable = '/usr/bin/python' – Monika Sulik Oct 28 '10 at 09:58
  • it's normal the sys.executable will not change , you can try running a python interpreter of a virtual environment and you will see that sys.executable == '/usr/bin/python', that because sys.executable don't give you the interpreter that's being run but give you the system default interpreter. – mouad Oct 28 '10 at 10:15
  • Actually no - when I run an interpreter via putting in something like /home/user/.virtualenv/env_name/bin/python2.7 into the command line then when I print sys.executable that's exactly what it says. – Monika Sulik Oct 28 '10 at 13:25
  • 1
    I don't think think that wiki page is actually wrong. If you check the [python documentation here](https://docs.python.org/2/library/os.html#process-management) it says that "the first of these arguments is passed to the new program as its own name" so passing the INTERP path twice is correct: once to invoke that interpreter, and again to tell it its own location. – bjmc Jun 25 '14 at 04:30
-3
>>> import os
>>> help(os.execl)


execl(file, *args)
    execl(file, *args)

    Execute the executable file with argument list args, replacing the
    current process.

This might help with your problem: http://ubuntuforums.org/showthread.php?t=1493979

kanaka
  • 70,845
  • 23
  • 144
  • 140
  • Thanks, but I still don't get it... Why do I have to put in the value of INTERP as both the filename and one of the arguments? And what does "replacing the current process" mean exactly? What about the error message, what does that mean? – Monika Sulik Oct 26 '10 at 16:02
  • 1
    @Monika Sulik : replacing the current process mean that the exec* command don't kill and create a new process ,they just replace the process from which the command have been called , the process ID doesn't change, but the data, heap and stack of the calling process are replaced by those of the new process. – mouad Oct 26 '10 at 16:14
  • @singularity - thanks, that really did clear at least the process thing up for me :) – Monika Sulik Oct 26 '10 at 16:26