Bug#230419: apache: will not install unless /etc/init.d/apache pre-exists
On Sat, 31 Jan 2004, David Morse wrote: Maybe I apt-get remove'd apache, but forgot apache-common. I'm pretty sure I didn't use a non-apt-get technique to remove. apache-common doesn't contain the init script or the cronjobs so i don't think this is relevant in our case. Hey, can you mail me the default /etc/init.d/apache ? It is inside the .deb. Just unpack it with dpkg. But i would suggest you to use apt-get to remove/install packages other than dpkg. Since you are installing try this: apt-get --purge remove apache-common apt-get install apache and let me know if this will solve the problem No, it didn't, but on the other hand, extracting /etc/init.d/apache helped, so at least I'm rolling. hmmm.. i am afraid there is something seriously inconsistent in your system at this poing. Another potentially wierd thing in this setup, is that roxen2 is already running, and sitting on port 80. (I intend to run apache on 8080, eventually). this is not an issue... just change the Port/Listen entries in httpd.conf other apache will refuse to start since port 80 is already in use. If you would like, you can get ssh access to the machine and poke around. That would require me to have root access and to be able to perform tests installing/removing apache and i doubt you can provide that (of course you can than i will be glad to look at this problem [0]). But at this point in time i don't think it is an apache bug at all but something related to your system. Fabio [0] in case we can discuss this issue on private emails since there are ways that can ensure you some safety while performig this operations. -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Processed: Re: Bug#230539: apache: SEGV when Including itself (recursive Include)
Processing commands for [EMAIL PROTECTED]: forwarded 230539 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26575 Bug#230539: apache: SEGV when Including itself (recursive Include) Noted your statement that Bug has been forwarded to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26575. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Potential affiliate
Hello: I would like to sell your products/services on a commission basis. For this purpose I would like to use my highly targeted B2B email list, which allows to contact businesses (over 64,000) advertising on the main pay-per-click search engines, such as Overture, Google AdWords, etc. These companies invest in advertising and bus. devepolment a lot, and thus they are perfect to make business with. Though this email list hits your target audience and is of very high quality, it is NOT opt-in. However we know how to meet the criteria of CAN Spam Act and how to run the campaign in a secure and legal mode. Please email me to [EMAIL PROTECTED] (only this email!) and I will share my thoughts on setting up the campaign. Your ideas for turning this list into opt-in are most welcome too!! Best, Michael Gallo * Private, Confidential and Privileged. This email and any files and attachments transmitted with it are confidential and/or privileged. They are intended solely for the use of the intended recipient. The content of this email and any file or attachment transmitted with it may have been changed or altered without the consent of the author. If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, circulation or transmission of this email and/or any file or attachment transmitted with it, is prohibited and may be unlawful. *
Re: more visible apache development process
On Sat, 31 Jan 2004, Fabio Massimo Di Nitto wrote: Hi all, I forgot to add that i am also quite often available on IRC irc.oftc.net #debian-apache but remember that this is a channel were we discuss only development status/bugs/issues for the debian packages and not general configuration problems. Thanks Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Bug#230660: apache: Fails to start after upgrade
Hi Fabio,
strace apache -X -F ends with:
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x48bec000
read(6, ### etherconf DEBCONF AREA. DO N..., 4096) = 366
read(6, , 4096) = 0
close(6)= 0
munmap(0x48bec000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(192.168.75.1)}, 28) = 0
send(6, \327\335\1\0\0\1\0\0\0\0\0\0\0011\00275\003168\003192\7..., 43, 0) =
43
gettimeofday({1075664459, 766137}, NULL) = 0
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(6, FIONREAD, [112]) = 0
recvfrom(6, \327\335\205\200\0\1\0\1\0\1\0\1\0011\00275\003168\003..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(192.168.75.1)}, [16]) = 112
close(6)= 0
getuid32() = 0
stat64(/etc/krb5.conf, 0xbfff6e4c)= -1 ENOENT (No such file or directory)
stat64(/usr/etc/krb5.conf, 0xbfff6e4c) = -1 ENOENT (No such file or directory)
open(/dev/urandom, O_RDONLY) = 6
fstat64(6, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
read(6, \221 =\224Z\203\335\2449$l\377[\344\27\336\232G\35\330..., 20) = 20
close(6)= 0
getpid()= 9621
gettimeofday({1075664459, 770182}, NULL) = 0
getpid()= 9621
getpid()= 9621
open(/etc/krb5.keytab, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(/dev/urandom, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
And /etc/apache/modules.conf looks like this:
# Autogenerated file - do not edit!
# This file is maintained by the apache package.
# To update it, run the command:
#/usr/sbin/modules-config apache
ClearModuleList
AddModule mod_so.c
AddModule mod_macro.c
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
LoadModule php4_module /usr/lib/apache/1.3/libphp4.so
PS If you are running php4 please be sure to have php4-imap disable since
it is heavily broken.
Really? nasty.
Thanks,
Chris.
--
The information in this e-mail is confidential. It is intended solely for
the addressee. If you are not the intended recipient please reply to
the sender. You are hereby placed on notice that any copying,
publication or any other form of dissemination of this e-mail or its
contents is prohibited without express permission.
Bug#230660: apache: Fails to start after upgrade
Can you kindly send me the output of strace apache -X -F and /etc/apache/modules.conf? Thanks Fabio PS If you are running php4 please be sure to have php4-imap disable since it is heavily broken. On Sun, 1 Feb 2004, chris wrote: Package: apache Version: 1.3.29.0.1-5 Severity: grave Tags: sid Justification: renders package unusable Hi, Just upgraded to the latest packages from unstable, and apache no longer runs. apachectl configtest says the Syntax is OK, and if I run apache in the foreground I can get it to spew this to the /var/log/apache/error.log: setsid: Operation not permitted apache: setsid failed setsid() failed probably because you aren't running under a process management tool like daemontools Thanks in advance, Chris. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux lucifer.srv.uk.fruble.net 2.6.1 #1 Fri Jan 9 19:29:54 GMT 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.29.0.1-5 Support files for all Apache webse ii debconf 1.4.7Debian configuration management sy ii dpkg1.10.18 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-9 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.24-1 MIME files 'mime.types' 'mailcap ii perl [perl5]5.8.3-1 Larry Wall's Practical Extraction -- debconf information excluded -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Bug#230660: apache: Fails to start after upgrade
Ok please try to disable php4 entirely and see if it still segfault. Is
this all the output from the strace or only the last part???
Thanks
Fabio
On Sun, 1 Feb 2004, Chris Murton wrote:
Hi Fabio,
strace apache -X -F ends with:
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x48bec000
read(6, ### etherconf DEBCONF AREA. DO N..., 4096) = 366
read(6, , 4096) = 0
close(6)= 0
munmap(0x48bec000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(192.168.75.1)}, 28) = 0
send(6, \327\335\1\0\0\1\0\0\0\0\0\0\0011\00275\003168\003192\7..., 43, 0)
= 43
gettimeofday({1075664459, 766137}, NULL) = 0
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(6, FIONREAD, [112]) = 0
recvfrom(6, \327\335\205\200\0\1\0\1\0\1\0\1\0011\00275\003168\003...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(192.168.75.1)}, [16]) = 112
close(6)= 0
getuid32() = 0
stat64(/etc/krb5.conf, 0xbfff6e4c)= -1 ENOENT (No such file or
directory)
stat64(/usr/etc/krb5.conf, 0xbfff6e4c) = -1 ENOENT (No such file or
directory)
open(/dev/urandom, O_RDONLY) = 6
fstat64(6, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
read(6, \221 =\224Z\203\335\2449$l\377[\344\27\336\232G\35\330..., 20) = 20
close(6)= 0
getpid()= 9621
gettimeofday({1075664459, 770182}, NULL) = 0
getpid()= 9621
getpid()= 9621
open(/etc/krb5.keytab, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/dev/urandom, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
And /etc/apache/modules.conf looks like this:
# Autogenerated file - do not edit!
# This file is maintained by the apache package.
# To update it, run the command:
#/usr/sbin/modules-config apache
ClearModuleList
AddModule mod_so.c
AddModule mod_macro.c
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
LoadModule php4_module /usr/lib/apache/1.3/libphp4.so
PS If you are running php4 please be sure to have php4-imap disable since
it is heavily broken.
Really? nasty.
Thanks,
Chris.
--
Our mission: make IPv6 the default IP protocol
We are on a mission from God - Elwood Blues
http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Bug#230660: apache: Fails to start after upgrade
Fabio, Ok please try to disable php4 entirely and see if it still segfault. Is this all the output from the strace or only the last part??? Ok, with PHP disabled it runs ok. Yeah, it was the last part from the strace.. Thanks, Chris.
Processed: Re: Bug#230660: apache: Fails to start after upgrade
Processing commands for [EMAIL PROTECTED]: reassign 230660 php4 Bug#230660: apache: Fails to start after upgrade Bug reassigned from package `apache' to `php4'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Bug#230660: apache: Fails to start after upgrade
reassign 230660 php4-imap # Justification: Renders package unusable on apache severity 225056 grave merge 228900 230660 225056 thanks I experienced the same problem, it is indeed php4-imap who's the culprit. Just like many other experienced. Current suspect is it is something related to /dev, as in chroots this problem usually does NOT show up. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Backtrace php4-imap/apache SEGV
Hi All, I have a stable reporduction case now in a chroot, and have succeed in getting backtraces out of it. It is with a recompiled libssl0.9.7, without the db_strip, to get a more useful one. As I don't know much about gdb, any hints on getting better backtraces would be appreciated (I now just gdb'd /usr/sbin/apache with -X -F) If I understand things correctly, the SEGV happens deep in libssl0.9.7 (therefore the CC to it's maintainer), as this looks like insufficient error handling, but of course, this is just speculation. The problem is the starting point, mail_getquota. It's an internal function in PHP's imap module, used ONLY when the corresponding PHP functions are called. However, the SIGSEGV happens at startup, and in ny whole fscking chroot there is no single php script anywhere. So, it gets wrongly called? Then there must be a serious fuckup of symbols somewhere, or otherwise I really don't understand. It also states about a possible stack overwrite at the end of the bt, so there is an accidental buffer overflow somewhere? Or is this function called somehow on startup... that would be really wierd. In the case of the buffer overflow, I guess that stack trace is useless and just plain wrong? Any pointers on how to check this issue better? (my versions: apache 1.3.29.0.1-5 php4 4:4.3.3-4 (oops, indeed, chroot was not fully uptodate) php4-imap 4:4.3.3-5 (but this was, as it was newly installed) libssl0.9.7 0.9.7c-5~notstripped-by-jeroen) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076541248 (LWP 27379)] 0x401ea010 in strcmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x401ea010 in strcmp () from /lib/tls/libc.so.6 #1 0x447996f4 in ?? () #2 0x448221e4 in obj_name_cmp () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #3 0x447996f4 in ?? () #4 0x448cb6f4 in empty.0 () from /usr/lib/i686/cmov/libssl.so.0.9.7 #5 0x0001 in ?? () #6 0x0010 in ?? () #7 0x448998c4 in __JCR_LIST__ () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #8 0x080eb220 in ?? () #9 0x080eae78 in ?? () #10 0x4481dd24 in getrn () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #11 0x03149d58 in ?? () #12 0x080eae78 in ?? () #13 0x448cafc9 in ?? () from /usr/lib/i686/cmov/libssl.so.0.9.7 #14 0x080eb1e0 in ?? () #15 0x4481d8b5 in lh_insert () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #16 0x080eae78 in ?? () #17 0x080eb1e0 in ?? () #18 0xb2b8 in ?? () #19 0x44822383 in OBJ_NAME_add () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #20 0x080eb1e0 in ?? () #21 0x448d21c4 in ?? () from /usr/lib/i686/cmov/libssl.so.0.9.7 #22 0x03149d58 in ?? () #23 0x448998c4 in __JCR_LIST__ () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #24 0x080eae78 in ?? () #25 0x448cafc9 in ?? () from /usr/lib/i686/cmov/libssl.so.0.9.7 #26 0xb7b8 in ?? () #27 0x4482236b in OBJ_NAME_add () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 #28 0x080eae78 in ?? () #29 0x080eb1e0 in ?? () #30 0x00ba in ?? () #31 0x8001 in ?? () #32 0x448d2050 in __JCR_LIST__ () from /usr/lib/i686/cmov/libssl.so.0.9.7 #33 0x448cafc9 in ?? () from /usr/lib/i686/cmov/libssl.so.0.9.7 #34 0x4461c470 in mail_getquota () from /usr/lib/php4/20020429/imap.so Previous frame inner to this frame (corrupt stack?) (gdb) -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
debian-apache@lists.debian.org
(095) 980-65-36 , , -: ( 1) - 03.02.2004 04.02.2004 - - . . : I... -: . - . - . II. - . . - . III.PR - . -. . IV. - : , , . - . V. - . . - . - . . - -, , ,. (095) 980-65-36
Re: Bug#205553: Backtrace php4-imap/apache SEGV
On Mon, Feb 02, 2004 at 02:16:48AM +0100, Jeroen van Wolffelaar wrote: I have a stable reporduction case now in a chroot, and have succeed in getting backtraces out of it. It is with a recompiled libssl0.9.7, without the db_strip, to get a more useful one. As I don't know much about gdb, any hints on getting better backtraces would be appreciated (I now just gdb'd /usr/sbin/apache with -X -F) The problem is the starting point, mail_getquota. It's an internal function in PHP's imap module, used ONLY when the corresponding PHP functions are called. However, the SIGSEGV happens at startup, and in ny whole fscking chroot there is no single php script anywhere. So, it gets wrongly called? Then there must be a serious fuckup of symbols somewhere, or otherwise I really don't understand. It also states about a possible stack overwrite at the end of the bt, so there is an accidental buffer overflow somewhere? Or is this function called somehow on startup... that would be really wierd. There seem to be two problems at work here: one, that in spite of having recompiled libssl0.9.7, the function names listed appear to be fairly useless (possibly because the lib was never built with -g in the first place, so stripping the library or not doesn't make a difference), and two, that the stack is a royal mess and appears to be at least partially (if not wholly) corrupted. For instance, it's a safe bet that 0x0001 and 0x0010 appearing on the stack indicates a bug. This is pretty much in keeping with the other backtraces I've seen of this bug, which is why (combined with other problems such as apache's double-initialization startup and the fact that it's not reproducible on my own systems) it's been so hard to pin down. In the case of the buffer overflow, I guess that stack trace is useless and just plain wrong? I wouldn't trust any of the reported stack contents in this case as indicating the actual source of the bug, no. Regards, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#230718: apache: mod_mime_magic can't find /etc/apache/share/magic
Package: apache Version: 1.3.29.0.1-3 Severity: normal I just noticed the following error in /var/log/apache/error.log: [Sun Feb 1 21:18:03 2004] [error] (2)No such file or directory: mod_mime_magic: can't read magic file /etc/apache/share/magic As it turns out, it's been in the logs since last May. Looks like version 1.3.26 was in use at the time. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux olgas 2.4.23-1-686 #1 Sun Nov 30 20:51:10 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US) Versions of packages apache depends on: ii apache-common 1.3.29.0.1-3 Support files for all Apache webse ii debconf 1.3.22 Debian configuration management sy ii dpkg1.10.18 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.14.1.25-16Berkeley v4.1 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.24-1 MIME files 'mime.types' 'mailcap ii perl [perl5]5.8.2-2 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: false apache/server-name: localhost apache/document-root: /var/www apache/server-port: 80 apache/init: true apache/server-admin: [EMAIL PROTECTED] -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
