OpenWrt Forum Archive

Topic: bad interaction of perl and httpd: SIGCHLD disabled?

The content of this topic has been archived on 31 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Post #1
semenzato
7 Oct 2008, 18:17

After some minor changes, my previously perfectly working Perl cgi-bin script appears
to no longer produce output.  More precisely, httpd produces a blank page after running
the script.  If I run the Perl script manually, the correct output is produced.

If I enable warnings by starting the script with the line

#! /usr/bin/perl -w

the httpd log (obtained by running httpd -h/www -f -vvvv) shows this message:

Can't ignore signal CHLD, forcing to default.

which seems to indicate that httpd is mucking with signals.
The script appears to be running normally (I can log from the
script to a temp file) but the output is lost---either it's not flushed
out by the script when it exits, or it is discarded by httpd.

Either way, it's a pretty sorry state of affairs.  Should I switch to a different
http server?

Thanks!
Luigi

Post #2
semenzato
7 Oct 2008, 23:08

I need to correct myself.  The bug is not related to the signal handling.
There is something else going on that makes the perl script work when run from the shell,
and fail when invoked by httpd.  I haven't narrowed it down yet, but simple scripts
that don't read from standard input always work.

Post #3
semenzato
7 Oct 2008, 23:42

Sigh... I don't exactly enjoy letting the whole world know how much time I waste
because of one small glitch, but maybe this will be useful for someone.

There is nothing wrong with perl or httpd, except the willingness of the latter to
silently swallow incorrect output.  My perl script was outputting this:

Content-Type: text/html
<html>
<head>

without a blank line between the Content-Type line and the <html> line.
This makes the busybox httpd reject the output---quietly, as I said, even
with maximum verbosity.

Post #4
d1mag
8 Oct 2008, 08:22

I and several other developers have noticed that libpthread in uClibc-0.9.29 is seriously broken...
Can you try to recompile your firmware and all packages with uClibc-0.9.28.3 which contains an older (working) libpthread.

It would be nice to hear if this works for you as well. It has solved all problems for me so far, and I can't understand why uClibc-0.9.29 is used as default when it's not working correctly.

/Christian

The discussion might have continued from here.