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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
