Issue #26 new

File python is busy during virtualenv creation

Vladimir Mihailenco
created an issue

I am not sure that this is fab_deploy issue, but may be you know any good solution for this problem:

{{{ run: virtualenv --no-site-packages ve out: New python executable in ve/bin/python out: Traceback (most recent call last): out: File "/usr/local/bin/virtualenv", line 9, in <module> out: load_entry_point('virtualenv==1.6.1', 'console_scripts', 'virtualenv')() out: File "/usr/local/lib/python2.6/dist-packages/", line 795, in main out: never_download=options.never_download) out: File "/usr/local/lib/python2.6/dist-packages/", line 886, in create_environment out: site_packages=site_packages, clear=clear)) out: File "/usr/local/lib/python2.6/dist-packages/", line 1094, in install_python out: shutil.copyfile(executable, py_executable) out: File "/usr/lib/python2.6/", line 53, in copyfile out: fdst = open(dst, 'wb') out: IOError: [Errno 26] Text file busy: 've/bin/python' out:

Fatal error: run() encountered an error (return code 1) while executing 'virtualenv --no-site-packages ve' }}}

As I understand this happens because virtual env is in use by some process... How do you typically solve this problem? So far I just comment out virtual env creation :)

Comments (7)

  1. Mikhail Korobov repo owner

    I think I've observed this in past and resolved the issue by logging in to the server and killing the process but I don't remember what was that process (crontab job? stalled command waiting for input?). Maybe knowing more about the cause of such problems will help in resolving it, I don't know what to do with this issue now.

  2. Vladimir Mihailenco reporter

    I can stop/kill processes that uses python (WSGI handler and celery are main candidates), but it looks not very wise to stop everything in order to test virtualenv existent... What do you think about some checks to prevent virtualenv creation if it already exists, like isdir(env.conf.ENV_DIR)?

    PS I ask this question in Issues, because I don't know better place to do it...

  3. Vladimir Mihailenco reporter

    I have decorated virtualenv with following line in order to skip virtualenv creation if it already exists:

    from fabric.contrib.files import exists
    if not exists('envs/%s' % env.conf.INSTANCE_NAME):

    Is there any drawbacks?

  4. Mikhail Korobov repo owner

    Generally: yes, there are drawbacks. Currently all steps can be safely repeated if an error occurred in one step. With this change if virtualenv creation fails for some reason and then this reason gets fixed, virtualenv_create won't create the virtualenv on second call.

    But given that virtualenv_create is very simple I think the issue above is only theoretical and this change is fine.

  5. Don Spaulding

    I know this is an old issue, but having run into it recently, I think I have a little insight to throw out here.

    The virtualenv process that is running is running from the virtualenv that it is trying to create. The python interpreter inside the ve virtualenv is what is being used to run the virtualenv command itself.

    The if not exists() trick is certainly one way to mitigate the effects. Another would be to ensure that the ve virtualenv is not activated when you attempt to run the virtualenv command.

    Hope that helps, Don

  6. Log in to comment