Bug #2786

error 500 (mod_cgi.c.601) cgi died

Added by marcon 8 months ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


I'm using lighttpd/1.4.31 (ssl) (Aug 2 2016 17:54:53) - on a Debian wheezy ARM.

The cgi scripts are executed, but sometimes the browser receive the "500 Internal Server Error" instead of the cgi output.
I've checked the logs and the only relevant thing I see is

(mod_cgi.c.601) cgi died

Any help would be appreciated, thanks!

Associated revisions

Revision 3209f30d (diff)
Added by gstrauss 7 months ago

[core] handle if backend sends Transfer-Encoding (#2786)

It is still not a good idea for backend to send Transfer-Encoding unless
backend is mod_proxy, and mod_proxy should not currently receive chunked
response since mod_proxy sends HTTP/1.0 request.

If mod_proxy is changed to sent HTTP/1.1 request, then lighttpd would
need to check if client is HTTP/1.0 and would need to de-chunk and
remove any other transfer-codings if not supported by next-hop.

"error 500 (mod_cgi.c.601) cgi died"

Revision 51ff7ac5 (diff)
Added by gstrauss 7 months ago

[mod_cgi] status 200 OK if no hdrs (deprecated) (#2786)

set status 200 OK if CGI does not return CGI headers

This mode in lighttpd is deprecated and may be removed in the next major
release of lighttpd. CGI scripts should return a proper CGI header in
the response, even if that header is empty and followed by a blank line,
before return response body.

Without a proper CGI response header, the first line(s) of the response
might be incorrectly construed as being CGI response headers, especially
if they contain ':', and response may be corrupted. That is why this
mode is deprecated (and not supported in numerous other web servers).

The minimal valid CGI response header is "\n", which lighttpd will treat
as equivalent to "Status: 200\n\n"

"error 500 (mod_cgi.c.601) cgi died"


#1 Updated by gstrauss 8 months ago

  • Status changed from New to Invalid

Please petition the Debian lighttpd package maintainers to pick up patches from the 14 releases of lighttpd (and 657 commits) in the 4 1/2 years since lighttpd 1.4.31 was released.

If you have a problem with lighttpd 1.4.45 (latest version of lighttpd as I write this), then please re-open this bug. Otherwise, please file the bug in the Debian bug tracker.

#2 Updated by marcon 8 months ago

I've downloaded the latest version, and it looks slightly less prone to the error, but still affected. The log now looks like:

(mod_cgi.c.695) cgi died, pid: 23350


#3 Updated by gstrauss 8 months ago

That would appear to be indicative of a problem with your CGI. That line in lighttpd 1.4.45 in mod_cgi.c means that the process did not exit normally. The CGI was either killed by a signal or core dumped. If your CGI closes stdout before exiting, lighttpd will send the CGI a TERM signal, so if your CGI closes stdout before exiting and needs to do processing after closing stdout, then the CGI needs to trap SIGTERM.

#4 Updated by gstrauss 8 months ago

Regarding the output sent the client, is the client receiving the full response now with lighttpd 1.4.45, even if there is an entry in the log that the CGI died? Or is the response to the client still being truncated? Can you share the CGI?

#5 Updated by marcon 8 months ago

The client receive no response, only the error (same as 1.4.31 version). This is the cgi:

Steps to reproduce:
Connect to <host>/cgi-bin/imbuga.cgi (this cgi sleeps for 60 seconds to give us time)

Then on another browser tab <host>/cgi-bin/test_email.cgi

It will succeed at first, but if you keep do F5 (like, 32 times) on test_email eventually you'll hit the 500 error.

#6 Updated by gstrauss 8 months ago

The first thing I notice is that the CGI is not returning a proper CGI/1.1 response header before returning the response body.

Your json_ok() should start with

echo "Status: 200" 

and your json_noauth() should start with
echo "Status: 403" 

Otherwise, lighttpd (or other web servers) might think that the subsequent response is part of the CGI/1.1 header, not the response body.

If lighttpd never sees a blank line (which ends the CGI/1.1 response header), then lighttpd might think that the response in invalid (due to incomplete CGI/1.1 response header) and may return 500 error to the client.

#7 Updated by marcon 8 months ago

Many thanks! This solved my issue even on 1.4.31! :)

Also available in: Atom