Lighttpd

"kills lighty": i cannot reproduce that - it justs sends no content (and i don't have a problem with that).

and my error.log shows it:

2008-08-18 09:49:50: (mod_fastcgi.c.2579) send-file error: couldn't get stat_cache entry for: /path/to/nonexistent/fileordirectory

So... we need more information to help you. If lighty really crashes a backtrace would be good: http://trac.lighttpd.net/trac/wiki/HowToReportABug

the path looked like 200808061

This is a bug tracker, not a support forum. Post an example script which sends a correct sendfile header and show lighttpd doesn't work if you really think there is a bug here.

But first you told us lighty was killed and no error was shown, and now there was a error in the log?...

But first you told us lighty was killed and no error was shown, and now there was a error in the log?...

still no error on the log, I found out the path was invalid. Try
header("X-LIGHTTPD-send-file: 2006330");
?>
and lighty will crash

I get

2008-08-20 18:31:13: (../src/mod_fastcgi.c.2587) send-file error: couldn't get stat_cache entry for: 2006330

And i already told you to provide a backtrace.

here is a bt from gdb, doesn't look too useful, i'll try to get an strace soon

Starting program: /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
debugging using libthread_db enabled
Thread 0xb7c69ae0 (LWP 11365)

Program received signal SIGABRT, Aborted.
to Thread 0xb7c69ae0 (LWP 11365)
0xffffe424 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb7c93631 in raise () from /lib/libc.so.6
#2 0xb7c94e58 in abort () from /lib/libc.so.6
#3 0x08061927 in stat_cache_get_entry ()
#4 0x0806b90e in ?? ()
#5 0x080701ba in ?? ()
#6 0x000001c0 in ?? ()
#7 0x00000001 in ?? ()
#8 0x08074090 in ?? ()
#9 0x2e373231 in ?? ()
#10 0xb7cd181e in _int_malloc () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-- smuenzel

Starting program: /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c69ae0 (LWP 11365)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7c69ae0 (LWP 11365)]
0xffffe424 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb7c93631 in raise () from /lib/libc.so.6
#2  0xb7c94e58 in abort () from /lib/libc.so.6
#3  0x08061927 in stat_cache_get_entry ()
#4  0x0806b90e in ?? ()
#5  0x080701ba in ?? ()
#6  0x000001c0 in ?? ()
#7  0x00000001 in ?? ()
#8  0x08074090 in ?? ()
#9  0x2e373231 in ?? ()
#10 0xb7cd181e in _int_malloc () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-- smuenzel

the error.log ( there doesn't seem to be any real information )

2008-08-24 15:11:34: (log.c.136) server started
2008-08-24 15:11:34: (mod_fastcgi.c.1307) --- fastcgi spawning local
        proc: /home/stefan/projects/books/wwwbook.rb
        port: 0
        socket /var/run/lighttpd/lighttpd-fastcgi-rb-books.socket
        min-procs: 4
        max-procs: 4
2008-08-24 15:11:34: (mod_fastcgi.c.1332) --- fastcgi spawning
        port: 0
        socket /var/run/lighttpd/lighttpd-fastcgi-rb-books.socket
        current: 0 / 4
2008-08-24 15:11:34: (mod_fastcgi.c.1332) --- fastcgi spawning
        port: 0
        socket /var/run/lighttpd/lighttpd-fastcgi-rb-books.socket
        current: 1 / 4
2008-08-24 15:11:34: (mod_fastcgi.c.1332) --- fastcgi spawning
        port: 0
        socket /var/run/lighttpd/lighttpd-fastcgi-rb-books.socket
        current: 2 / 4
2008-08-24 15:11:34: (mod_fastcgi.c.1332) --- fastcgi spawning
        port: 0
        socket /var/run/lighttpd/lighttpd-fastcgi-rb-books.socket
        current: 3 / 4
2008-08-24 15:11:42: (mod_fastcgi.c.2961) got proc: pid: 11380 socket: unix:/var/run/lighttpd/lighttpd-fastcgi-rb-books.socket-3 load: 1

-- smuenzel

when I print {{{X-LIGHTTPD-send-file: books.css}}}
a crash occurs, but with {{{/hello/world/books.css}}}, no crash occurs

-- smuenzel

I guess you are using

server.stat-cache-engine = "fam" 

Disable it and you should be fine.

Yes, you are correct, disabling it resolves the issue.

-- smuenzel

Fixed in r2299