0

I am trying to deploy the python web framework web2py on iis8 on Windows server 2012. I am using fastcgi, downloaded from microsoft, v 2.1 and python 2.7

web2py sometimes creates .py files under the docroot. When this happens, the IIS request thread crashes immediately with 500 errors "The FastCGI Process exited unexpectedly". I can reproduce this every time, for example by doing an extraction of a tar file using the python standard library in the request handler script.

If I get web2py to write outside of the docroot, the errors don't happen. So IIS is reacting when .py files are created. This is causing a conflict which crashes the request. Python exceptions are not reached. The request thread dies immediately. The file is left as 0 bytes. So the file is created by the python script executed to handle the request, but before it can be closed, the request process or thread dies. I don't know what IIS is doing or why, but does it do kind of file watching? I have turned off caching.

web2py sometimes tries to write .py files. It does this on two occasions: 1) when using its browser-based IDE to edit .py files such as 'controllers' 2) when creating a new application, because it untars a template application called welcome, and this involves writing .py files I have a controller which simulates (2). That is, as part of handling the browser request, it untars the bundle of files making up the template application, which includes .py files.

These problems have nothing to do with file system security because non .py files are ok. In any case, file permission errors would surely be handled by python exceptions or would be logged somewhere.

Concentrating on (2), the web request fails catastrophically as soon as it encounters the first .py files.

It looks like some kind of locking. I am scouring processmon but don't see anything interesting. I can get a request tracing log from IIS for the crashed request, but it doesn't offer any reason although I am not experienced at interpreting these files.

If I change the path used in (2) to be outside the document root of the IIS website, it works perfectly. Unfortunately this is not a work around; web2py needs to update and create files under the docroot.

So IIS is doing something when .py files added under its document root, and that something is not happening in the request actually running, but in some other thread or process. What ever that something is, kills the request thread probably due to a file system error which is not handled very well. The request thread seems to die immediately. I have copious logging statements, and the Python exception waiting for this file error is never reached.

The web2py code is mature and works under other http servers.

1
  • This problem has been solved by a web2py developer. Details will be posted soon. issue is with recent versions of Microsoft's wfastcgi.py script Oct 24, 2014 at 23:18

1 Answer 1

1

this happens because wfastcgi has a pretty specific section of code handling a watcher over the application directory for files changes. Unfortunately it trips up if a new file is added during the execution of a request. By default it restarts the process (in quite an abruptively way) for any *.py or *.config changes. It can be set, though, to watch only *.config files via the WSGI_RESTART_FILE_REGEX env variable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .