Project

General

Profile

Bug #2786

error 500 (mod_cgi.c.601) cgi died

Added by marcon almost 3 years ago. Updated almost 3 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
mod_cgi
Target version:
Start date:
2017-02-02
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

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!

#1

Updated by gstrauss almost 3 years 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 almost 3 years 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

Thanks!

#3

Updated by gstrauss almost 3 years 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 almost 3 years 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 almost 3 years ago

The client receive no response, only the error (same as 1.4.31 version). This is the cgi: https://drive.google.com/open?id=0B4fjLZeeYfAxczdVeDVpX1FQTU0

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 almost 3 years 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" 
echo

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

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 almost 3 years ago

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

Also available in: Atom