Bug#307567: apache2-common: Apache2 consumes 100% CPU after a few requests
Package: apache2-common Version: 2.0.54-2 Severity: grave Justification: renders package unusable It seems that the problem is related to LDAP authentication. The problem started showing up after the last 'aptitude upgrade' which has upgraded both the Apache2 server from 2.0.53 to 2.0.54, and libc6 I tried to disable the ldap cache feature in the util_ldap Apache2 module, with no success I also tried with the prefork and the worker variants: same issue. After a couple of requests to a URL which requires authentication, the Apache2 server starts eating up to 100% of CPU time. The problem does not show up with public access (ie no LDAP validation). The LDAP server works nicely with other clients, such as ldapsearch. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.22-1-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apache2-common depends on: ii apache2-utils 2.0.54-2 utility programs for webservers ii debconf 1.4.30.13Debian configuration management sy ii debianutils 2.8.4Miscellaneous utilities specific t ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libgcc1 1:3.4.3-12 GCC support library ii libmagic1 4.12-1 File type determination library us ii mime-support3.28-1 MIME files 'mime.types' 'mailcap ii net-tools 1.60-10 The NET-3 networking toolkit ii openssl 0.9.7e-3 Secure Socket Layer (SSL) binary a ii ssl-cert1.0-11 Simple debconf wrapper for openssl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307567: apache2-common: Apache2 consumes 100% CPU after a few requests
On Wed, May 04, 2005 at 01:08:37AM +0200, Emmanuel Blot wrote: Package: apache2-common Version: 2.0.54-2 Severity: grave Justification: renders package unusable It seems that the problem is related to LDAP authentication. The problem started showing up after the last 'aptitude upgrade' which has upgraded both the Apache2 server from 2.0.53 to 2.0.54, and libc6 I tried to disable the ldap cache feature in the util_ldap Apache2 module, with no success I also tried with the prefork and the worker variants: same issue. After a couple of requests to a URL which requires authentication, the Apache2 server starts eating up to 100% of CPU time. The problem does not show up with public access (ie no LDAP validation). I'm not familiar with apache internals, nor LDAP, but I can try to help begin diagnosis. Could you provide a strace of the process when it is in that state? (strace -p pid)? Maybe also a strace of the process beginning before it is in that state, and ending sometime after it has gone into that state. Maybe also a gdb backtrace? (LD_LIBRARY_PATH=/usr/lib/debug gdb -p pid); you should first install the package libc6-dbg, if possible. If not, then don't set LD_LIBRARY_PATH. It will at least tell us if the stack is still sane, or if there has been memory corruption. Depending on the result, I (or someone else) may request that you do (or do not) compile some software with debugging enabled, which might give the backtrace much more info. Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307567: [Fwd: [Fwd: Re: Bug#307567: apache2-common: Apache2 consumes 100% CPU after a few requests]]
[Sorry, I posted with the wrong email account] I'm not familiar with apache internals, nor LDAP, but I can try to help begin diagnosis. Thanks. Could you provide a strace of the process when it is in that state? (strace -p pid)? Maybe also a strace of the process beginning before it is in that state, and ending sometime after it has gone into that state. Here it is. I'm not familiar with bug reporting w/ Debian: I've gzipped the log, to keep this email small. If I should have sent it as plain ASCII, please let me know. Here's what I did to obtain this trace: /etc/init.d/apache2 start # use prefork ps ax | grep apache2 # to get the PIDs - 23224 to 23229 sudo strace -p 23224 ... -p 23229 21 | tee ~/apache2.strace I then run a small script that use wget to stress the webserver from another console, until the script got deadlocked (as the server does not answer the request when it consumes 100% CPU), then broke the strace execution (Ctrl+C) top # to get the PID of the process eating up the CPU time grep [pid] ~/apache2.strace | gzip -c apache2.strace.23229.gz I then restarted strace -p 23229, but strace does not show any other trace for this process. I'll come back later in another email with the GDB trace, if I manage to get it. Thanks for your support, Emmanuel apache2.strace.23229.gz Description: Binary data
Bug#307584: apache2-common: Rename /etc/apache2/conf.d/apache2-doc to apache2-doc.conf
Package: apache2-common Version: 2.0.54-2 Severity: normal With the last update only files named *.conf in the conf.d directory are included by apache2.conf. Therefore /etc/apache2/conf.d/apache2-doc needs to be renamed to /etc/apache2/conf.d/apache2-doc.conf -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.22-bf2.4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apache2-common depends on: ii apache2-utils 2.0.54-2 utility programs for webservers ii debconf 1.4.30.13Debian configuration management sy ii debianutils 2.8.4Miscellaneous utilities specific t ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libgcc1 1:3.4.3-12 GCC support library ii libmagic1 4.12-1 File type determination library us ii mime-support3.28-1 MIME files 'mime.types' 'mailcap ii net-tools 1.60-10 The NET-3 networking toolkit ii openssl 0.9.7e-3 Secure Socket Layer (SSL) binary a ii ssl-cert1.0-11 Simple debconf wrapper for openssl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
