[Bug 375] httpd does not reap zombies

bugzilla at busybox.net bugzilla at busybox.net
Thu Jul 16 12:54:55 UTC 2009


https://bugs.busybox.net/show_bug.cgi?id=375





--- Comment #7 from Denys Vlasenko <vda.linux at googlemail.com>  2009-07-16 12:54:54 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > What is your environment? Most importantly, what version of busybox?
> 
> It is an STLinux-2.3 environment, running kernel 2.6.23.17_stm23_0117 on a
> STMicro based board (Hitachi SuperH 4 processor).
> The supplied busybox version is 1.8.2 in source RPM format, patched by STM for
> compatibility with their init scripts.

Can you send the RPM to vda.linux at googlemail.com?


> > See? We did not get SIGCHLD, since kernel knows we aren't interested. Now I
> > Ctrl-C it:
> > 
> > 15969 21:37:05.224937 --- SIGINT (Interrupt) @ 0 (0) ---
> > 15969 21:37:05.225069 +++ killed by SIGINT +++
> > 
> > I will attach complete LOG.
> > 
> > 
> > I also ran "./busybox httpd -f -p88 -vvv -h /.1/video", then refreshed
> > http://127.0.0.1:88/ a dozen times in the browser, then ran ps -A and I
> > definitely do not see any zombies.
> > 
> 
> But what did the web browser request from httpd in busybox?
> 
> I could see that if the browser requests regular files that it can serve
> locally from /home/httpd/html/, or if it requests a cgi-bin script that resides
> under /home/httpd/cgi-bin/ - everything works OK.

You can see it in strace log I attached. Please read it.
It requests /, and httpd runs cgi-bin/index.cgi:

15971 21:37:02.334556 read(0, "GET / HTTP/1.1\r\nHost: ..."..., 1025) = 374
15971 21:37:02.334719 write(2, "[::ffff:127.0.0.1]:47252: url:/\n", 32) = 32
...
15971 21:37:02.335707 alarm(60)         = 60
15971 21:37:02.335803 alarm(0)          = 60
15971 21:37:02.335899 stat64("index.html", 0xffcbc998) = -1 ENOENT
15971 21:37:02.336006 access("cgi-bin/index.cgi", X_OK) = 0
15971 21:37:02.336119 stat64("cgi-bin", {st_mode=S_IFDIR|0755, st_size=80,
...}) = 0
15971 21:37:02.336288 pipe([3, 5])      = 0
15971 21:37:02.336395 pipe([6, 7])      = 0
15971 21:37:02.336503 vfork( <unfinished ...>
...pid 15969 syscalls skipped (they are irrelevant)...
15971 21:37:02.337061 <... vfork resumed> ) = 15972
15972 21:37:02.337148 close(7)          = 0
15972 21:37:02.337245 close(3)          = 0
15972 21:37:02.337345 dup2(6, 0)        = 0
15972 21:37:02.337442 close(6)          = 0
15972 21:37:02.337538 dup2(5, 1)        = 1
15972 21:37:02.337633 close(5)          = 0
15972 21:37:02.337746 chdir("cgi-bin")  = 0
15972 21:37:02.337861 rt_sigaction...  {skipped a few of these}
15972 21:37:02.338209 execve("index.cgi", ["index.cgi"], [/* 47 vars */]) = 0

> But, if it requires an execution of an external interpreter, using the PHP
> external interpreter method, I get the described problem.
> 
> Is it possible that by the phrase "external interpreter" it is meant to be a
> shell (or other) script, and not a C application so the shell can take care of
> such signals?

httpd uses the same method for all CGIs.

> Could it be that the C application should be implemented differently than the
> httpd_indexcgi.c sample code, and maybe handle such signals on its own?

I think all CGIs should just dump result to stdout and exit, regardless of the
language they use (C, shell, PHP etc). No special handling of exit signal is
needed.

Can you produce a strace log and show "ps -AH" output fragment which shows
zombies being created?


-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list