Hi again all.
Hmm.. this is embarassing.. the problem has been found (and it was
indeed the PHP-app).
The problem was, that I tested on a full copy of the live installation
and the 404 handler and the index file had the error in common (and when
going to // on the server one hits the index-file,
Hi.
I am currently investigating a misbehaving apache httpd 2.2.21 with apr
1.4.5 on linux 64-bit.
I have a virtual domain defined as (it runs behind a 1-on-1 nat, hence
the rfc 1918 address) :
VirtualHost 192.168.3.2:80
ServerName sub.domain.tld
ServerAdmin webmas...@sub.domain.tld
Can't reproduce it with the same versions/arch. Although I have noticed
those urls lately on one of servers I am taking care of.
The only difference is: i'm using *:80 as Listen address, not IP:80.
b.
On 24 October 2011 18:02, Svenne Krap svenne.li...@krap.dk wrote:
Hi.
I am currently
Svenne,
When troubleshooting issues like this, I often use strace to attach to
the pid of the program in questions. A lot of times seeing what the
process is doing when pegged at 100% CPU will lead you to the
solution.
The nice thing about strace is you can attach to the already running
process
When I attach to the process with strace all i get is :
read(7,
And it blocks (for several minutes at least) while the cpu is 100%.
Svenne
On 24-10-2011 20:58, Ben Timby wrote:
Svenne,
When troubleshooting issues like this, I often use strace to attach to
the pid of the program in
This means that your httpd process is stuck waiting for file descriptor
number 7.
You should now look at what this file descriptor is. lsof command is
useful here: lsof -p PID where PID is the PID number of the stuck process.
In the fourth column look for number 7 followed by either r, w or u (or
