Those darned "spawning fastcgi failed"-errors in lighttpd deployment...

[Adam Bengtsson]

I simply cannot get my new web.py app running from lighttpd. I had this problem earlier and wrote about it in a previous post and after some help I discovered my shebang-lines where wrong.

This time however the shebangs aren't off, and the error code is also not the same as before (when the shebang was off I got "child exited with status 2", now it's "child exited with status 127"), so I'm really at my wits end as to what the problem might be.

The application is the basic Hello World-example, it runs fine from the development server, the lighttpd user is the owner of the file and it is chmoded to be an executable.

Is there anyone with some insight into what these different status codes means, particularly 127?

//Adam

Error log output:

2012-08-23 14:52:15: (log.c.166) server started 

2012-08-23 14:52:15: (mod_fastcgi.c.1104) the fastcgi-backend /var/www/mydomain.com/webpy/index.py failed to start: 

2012-08-23 14:52:15: (mod_fastcgi.c.1108) child exited with status 127 /var/www/mydomain.com/webpy/index.py 

2012-08-23 14:52:15: (mod_fastcgi.c.1111) If you're trying to run your app as a FastCGI backend, make sure you're using the FastCGI-enabled version.

If this is PHP on Gentoo, add 'fastcgi' to the USE flags. 

2012-08-23 14:52:15: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed. 

2012-08-23 14:52:15: (server.c.938) Configuration of plugins failed. Going down.

[Primoz Anzur]

From what I gather; error 127 in lighty means problem with paths... Have you checked your environment? Does your http user have access to the script?

--
You received this message because you are subscribed to the Google Groups "web.py" group.
To view this discussion on the web visit https://groups.google.com/d/msg/webpy/-/oIJ461dyl2YJ.
To post to this group, send email to we...@googlegroups.com.
To unsubscribe from this group, send email to webpy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/webpy?hl=en.

[Adam Bengtsson]

Problem with paths in what way? The paths I've entered in lighttpd.conf looks in order and all files are owned by the lighttpd user.

I've tried putting my non-working web.py-app in the folder of the working web.py-app (hiding the error-free app) and restarting the server, but I still get the 127 exit status, so perhaps I've made some mistake in my Python code? As mentioned previously the app works fine in development, and the project is really nothing more than the hello world-example...

//Adam

[Primoz Anzur]

Script is set to be executable and the owner the same as Lighty, I assume? Can you post the excerpt of the lighty config where you call that part? Can you re-check the paths?

To view this discussion on the web visit https://groups.google.com/d/msg/webpy/-/KkrviEjg8ekJ.

[Adam Bengtsson]

The parts in my lighttpd.conf pertaining to the domain and app in question (I've got some more domains running on the same server) looks like below. The filenames are correct, executable and has the proper ownership.

$HTTP["host"] == "mydomain.com" {

        server.document-root     = "/var/www/mydomain.com/htdocs/"

        server.errorlog          = "/var/www/mydomain.com/logs"

        fastcgi.server = ("/index.py" =>

                (( "socket" => "/tmp/mydomain_fastcgi.socket",

                        "bin-path" => "/var/www/mydomain.com/webpy/index.py",

                        "max-procs" => 1,

                        "bin-environment" => (

                                "REAL_SCRIPT_NAME" => ""

                        ),

                        "check-local" => "disable"

                )))

        url.rewrite-once = (

                "^/static/(.*)$" => "/static/$1",

                "^/(.*)$" => "/index.py/$1"

        )

}

//Adam

[Adam Bengtsson]

I've finally resolved this issue.

The difference between the working and non-working web.py app was CRLF terminators in the non-working app files, it looks as Filezilla put the additional line breaks in when transfering in ASCII mode.

Apparently it is only the python-file called by fastcgi where this is an issue, additional files imported by webpy can have the CRLFs and not cause an error.

//Adam

[Levi Self]

Thanks for posting! I had the same issue and may never have thought to look for this. I was migrating from web.py on Apache which did not care about the line terminators.