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
Den fredagen den 24:e augusti 2012 kl. 20:12:51 UTC+2 skrev 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
>
> Den torsdagen den 23:e augusti 2012 kl. 20:32:22 UTC+2 skrev 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?
>>
>> On Thu, Aug 23, 2012 at 3:32 PM, Adam Bengtsson <ada...@gmail.com> wrote:
>>
>>> 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
>>>
>>> Den torsdagen den 23:e augusti 2012 kl. 14:43:49 UTC+2 skrev 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?
>>>>
>>>> On Thu, Aug 23, 2012 at 1:20 PM, Adam Bengtsson <ada...@gmail.com>wrote:
>>>>
>>>>> 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 <http://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<http://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.
>>>>>
>>>>> --
>>>>> 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<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 <http://groups.google.com/group/webpy?hl=en>.
>>>>>
>>>>
>>>> --
>>> 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/-/KkrviEjg8ekJ.
>>>
>>> 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.
>>>
>>
>>
--
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/-/3ElWINyx9gEJ.
To post to this group, send email to webpy@googlegroups.com.
To unsubscribe from this group, send email to
webpy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/webpy?hl=en.
