Bug#396631: strace of failing file serves

[Branden Robinson <branden@debian.org>]

Package: apache2
Version: 2.2.3-3
Followup-For: Bug #396631

An strace of apache2 -X?

Yeah, I can do that.

Incidentally, this bug renders all my CSS and images on my sites and wikis
useless, and manages to keep some CGI scripts from functioning as well.
IMO apache2 is not ready for stable with a bug this bad, but I'm not an RM,
and it probably works on amd64...

Anyway.

First thing to note is that ptrace howls; see below:

necrotic:/var/www# strace -o apache2 -ff apache2 -X
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
[Wed Nov 15 01:15:02 2006] [warn] NameVirtualHost *:0 has no VirtualHosts
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error
ptrace: umoven: Input/output error

Here's the actual strace output, stripped down to the part that I think
matters.

You can find the full strace output -- assuming this bug doesn't prevent my
apache2 from serving it to you ;-) -- at:

http://necrotic.deadbeast.net/apache2

(Hmm, it does prevent it.  Find it here instead:

http://redwald.deadbeast.net/tmp/apache2.txt

Yeesh.)

read(9, "GET /tmp2/IMG_3819.JPG HTTP/1.1\r"..., 8000) = 497
gettimeofday({1163571317, 379807}, NULL) = 0
stat64("/var/www/tmp2/IMG_3819.JPG", {st_mode=S_IFREG|0644, st_size=1133935, ...}) = 0
getpid()                                = 435
open("/var/www/tmp2/IMG_3819.JPG", O_RDONLY|O_LARGEFILE) = 10
rt_sigtimedwait([?], 0x6, 0x1, -268448520) = 0
rt_sigtimedwait([?], 0x6, 0x3, -268448428) = 0
writev(9, [{"HTTP/1.1 200 OK\r\nDate: Wed, 15 N"..., 310}], 1) = 310
sendfile64(9, 10, [0], 1133935)         = -1 ENOSYS (Function not implemented)
rt_sigtimedwait([?], 0x6, 0x3, -268448428) = 0
rt_sigtimedwait([?], 0x6, 0x1, -268448520) = 0
read(9, 0x1e42f0, 8000)                 = -1 EAGAIN (Resource temporarily unavailable)
write(8, "65.29.71.69 - - [15/Nov/2006:01:"..., 242) = 242
close(9)                                = 0
read(4, 0xeffff607, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
close(10)                               = 0
accept(3, {sa_family=AF_INET, sin_port=htons(44113), sin_addr=inet_addr("65.29.71.69")}, [16]) = 9
getsockname(9, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.1.1.199")}, [16]) = 0
fcntl64(9, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(9, F_SETFL, O_RDWR|O_NONBLOCK)  = 0

It looks like apache2 may be assuming sendfile64() is available, and has no
fallback prepared if it's not.

I will note that it's pretty perverse to report success both in the HTTP
header *and* in the log file.  Silent failure is bad.  Failure that
disguises itself as success is worse.

Versions of packages apache2 depends on:
ii  apache2-mpm-prefork           2.2.3-3    Traditional model for Apache HTTPD

apache2 recommends no packages.

-- no debconf information