lighttpd, web.py, spawning fcgi failed

The other day I was trying to deploy my newly written app on my VPS. It’s written based on the neat framework of web.py and I was planning to deploy it on lighttpd through fastcgi.

The process was not very smooth for me, as we always expect when trying out new things. The lighttpd server failed to start and by looking into the error log I found these lines:


2009-12-15 19:48:04: (server.c.1503) server stopped by UID = 0 PID = 25128 2009-12-15 19:48:30: (log.c.166) server started
2009-12-15 19:48:30: (mod_fastcgi.c.1104) the fastcgi-backend /var/www/code.py failed to start:
2009-12-15 19:48:30: (mod_fastcgi.c.1108) child exited with status 1 /var/www/code.py
2009-12-15 19:48:30: (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.
2009-12-15 19:48:30: (mod_fastcgi.c.1399) [ERROR]: spawning fcgi failed. 2009-12-15 19:48:30: (server.c.931) Configuration of plugins failed. Going down.

Finally I got it to work and here I’ll provide a check list in case someone else encounter the same problem.

Is code.py executable?

If not:

chmod 755 code.py

Also you need something like this on top of file:

#!/usr/bin/env python

Does helloword example work?

Use the example on web.py’s homepage (remember to add the line of python executable to the top of the file):


#!/usr/bin/env python
import web

urls = (
    '/(.*)', 'hello'
)
app = web.application(urls, globals())

class hello:        
    def GET(self, name):
        if not name: 
            name = 'world'
        return 'Hello, ' + name + '!'

if __name__ == "__main__":
    app.run()

Chances are this will work. Because this app is so simple and it doesn’t require many libraries.

check egg cache dir permission

Some libraries need to extract files to a directory (python egg cache). I used MySQL-python in my program and it might fail on that.
/sbin/.python-eggs/
Now change the GET method of hello class to:


try:
    import MySQLdb
except Exception, e:
    return str(e);
return 'hello'

If egg cache permission is the cause, you’ll see something like this when visiting the server:

Can’t extract file(s) to egg cache The following error occurred while trying to extract file(s) to the Python egg cache: [Errno 13] Permission denied: ‘/sbin/.python-eggs’ The Python egg cache directory is currently set to: /sbin/.python-eggs Perhaps your account does not have write access to this directory? You can change the cache directory by setting the PYTHON_EGG_CACHE environment variable to point to an accessible directory.

There are many ways to solve this problem, but I just changed the owner of this directory to the user who runs lighttpd (daemon in my case):

chown -R daemon.daemon /sbin/.python-eggs

Is lighttpd using the expected version of python?

My VPS is running CentOS 5.4 and I installed python 2.6 on it (CentOS ships with old 2.4 version). I have two python executables (/usr/local/bin/python and /usr/bin/python) on my $PATH, but python 2.6 has precedence on mine (root). At last it turned out that lighttpd was using the old python 2.4

So I changed the first line of code.py to be:

#!/usr/local/bin/python

Now lighttpd can start happily.

When working in an old system

Today I needed to pull some web page down from the internet and extract some specific contents in PHP. Sounds like a crawler, huh? Actually not the real crawler, just pulling our own contents. I was doing this because it’s not convenient for me to access the database directly.

I’m not quite familiar with PHP, but with version 5 on my local dev machine, I was able to do this very quickly. Just use file_get_contents to get the whole page as a string, and then use preg_match_all to search for the parts I want.

Unexpected things happened after I uploaded the script to the server. It said function file_get_contents was not defined. Then I realized that I was on a machine with Red Hat 9, the PHP I was using was version 4.2.2 bundled with RH9. OK. I rewrote the code to use fopen/fread directly. This time, it complained that it couldn’t handle the scheme (I don’t remember the error report string clearly).

I don’t know if it was because of my configuration, or version 4.2.2 doesn’t support the wrappers. It made me crazy. I don’t want to do an upgrade because all the packages are old. It takes time and may cause more problems. I even couldn’t find the apxs binary to compile PHP from source.

Finally, I got a workaround. First use exec to call wget to download the url to a file in /tmp, and then use fopen/fread to read this temp file. It really works.

Another problem was that preg_match_all doesn’t accept the last $offset parameter in PHP 4.2.2, but it’s simple to fix, I think.

This took me some time, but made me realize that how the development of software/language tools eased our daily work.

MyBlogLog Changed its Widget Theme

Half a year ago I wrote a small tool for customizing MyBlogLog widget. And, since then I didn’t notice the changes MyBlogLog has done.

As I noticed there are some problems with the widget colorer, I checked MyBlogLog and found that they’ve changed the widget theme.

Well, the new theme is polished and cool but lacks flexibility due to the gradient background.

So I must mark the project as “obsolete”. But people still can play around with it, and the “obsolete” code can still be used on websites.

Google Maps API’s Error Handling

Requirements to try out things described below:

Super large numbers as LatLng’s

Open this page from Google’s example. In firebug’s console, execute the following code:

map.setCenter(new GLatLng(1e100, 1e100));

Setting super large numbers as latitude and longitude like this always makes my Firefox 2.0.0.11 in Windows XP hang.

I don’t know why Google didn’t restrict the range of the numbers, and what computation it did to consume so much CPU time. It should ignore such numbers after a simple judgment.

Strings as zoom parameters

In the same page, execute this piece of code:

var zoom = '16';
map.setZoom(zoom);

As you see, nothing happens. Google must be ignoring the parameter when expression typeof(zoom) == ‘number’ is false. In my situation, I got the value of variable zoom from the url, and didn’t noticed it was the type mismatch which prevented the code to work, since I’m used to JavaScript’s dynamic type conversion feature:

a = 2 * '3'; // a = 6

It will be converted to number when needed. Of course, it’s good to perform strict type checking. But it’ll be better if the API threw an exception instead of being silent.

Remove Dotted Link Borders in Firefox

When you use a HTML link (“<a>” tag) to implement a drop-down list or menu, you’ll notice that there are annoying dotted borders around the link after it’s clicked in Firefox. We can just ignore this for most of the times but sometimes it affects the look and feel of the site. Two screen shots from Youtube and Yahoo!:

Youtube link border example      Yahoo link border

This can be even worse (Digg front page):

Digg Link Border

OK. This is fake :) . Digg did a perfect drop-down menu, though they’re ignoring something. I removed some CSS rules using Firebug and got this effect. It’s ugly, isn’t it?

The Cause

When a link is clicked, it gets the focus. Firefox adds dotted borders to links that have focus to remind the users.

The Solution

To avoid the border, add this CSS rule to your page:

a {
outline: none;
}

This piece of code is similar to the code I removed from Digg to get the screen shot above.

In fact this is a common problem asked by many developers. For more information, search for “firefox link border“. Many authors wrote good articles on this topic.

Update – This can be seen on every WordPress blog login page (click to enlarge):

WordPress login

Small Flaw of StumbleUpon User List (Firefox only)

If you stumble a lot using Firefox, you must have already seen disordered user lists like this one (two blank seats in the second row):

StumbleUpon User List

This screen shot was taken from a page on StumbleUpon which received 35 reviews. StumbleUpon automatically finds out who’s living in the same city with you and places them in the beginning of the list. To make it more clear, StumbleUpon adds an “city” icon (city) in front of the user’s name.

Yes. This icon caused the mess of the list. Using Firebug to inspect the elements, I found the dimensions of the first two list items with city icon to be 145×89, whereas the other items in the list have dimensions of 145×88. This 1px difference, according to the CSS rule, made left-floating elements to be positioned on the right of them rather than under them.

In fact, just one more CSS rule will fix this issue:

div.listPeople dl {
line-height: 16px;
}

Another solution is to have “clear:both” style on each element starting a row.

This page looks OK in all other major browsers including IE 6, Opera 9.24 and Safari 3.0.4 as I tested. However market share of Firefox is growing steadily, so websites should pay enough attention on it. Besides, with the great power of Firebug, it’s much easier to develop a site for Firefox compared to the ancient browser – IE.