Problem with Apache22

2007-11-01 Thread Peter Uthoff
Hello,

I have a problem where my Apache procs are dying almost exactly every
ten
minutes as you can from the messages and web logs below:

Oct 25 10:34:44  kernel: pid 66337 (httpd), uid 80: exited on signal 4
Oct
25 10:35:33  kernel: pid 66357 (httpd), uid 80: exited on signal 4 Oct
25
10:45:11  kernel: pid 66395 (httpd), uid 80: exited on signal 4 Oct 25
10:55:21  kernel: pid 66340 (httpd), uid 80: exited on signal 4

Looking at the Apache logs, I find the following:

[Thu Oct 25 10:25:01 2007] [notice] child pid 66379 exit signal Illegal
instruction (4)
[Thu Oct 25 10:34:44 2007] [notice] child pid 66337 exit signal Illegal
instruction (4)
[Thu Oct 25 10:35:33 2007] [notice] child pid 66357 exit signal Illegal
instruction (4)
[Thu Oct 25 10:45:11 2007] [notice] child pid 66395 exit signal Illegal
instruction (4)

I tried upping the logs all the way to debug today and it really wasn't
very helpful:

[Wed Oct 31 15:59:19 2007] [debug] prefork.c(991): AcceptMutex: flock
(default: flock)
[Wed Oct 31 16:05:39 2007] [notice] child pid 73668 exit signal Illegal
instruction (4)
[Wed Oct 31 16:12:01 2007] [info] server seems busy, (you may need to
increase StartServers, or Min/MaxSpareServers), spawning 8 children,
there
are 4 idle, and 17 total children
[Wed Oct 31 16:15:04 2007] [notice] child pid 73779 exit signal Illegal
instruction (4)
[Wed Oct 31 16:15:28 2007] [notice] child pid 73717 exit signal Illegal
instruction (4)
[Wed Oct 31 16:18:37 2007] [notice] child pid 95939 exit signal Illegal
instruction (4)

I don't believe the 'busy' message is accurate. I think it's a result of
the procs dying constantly as I just don't get that much traffic. I also
have no idea what is causing the illegal instructions because none of
the logs point out any specific detail to help me track it down.

I'm running the following:

FreeBSD 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #3: Thu Oct 25 20:04:14
CDT
2007  :/usr/obj/usr/src/sys/GENERIC  i386

apache-2.2.6_2  Version 2.2 of Apache web server with prefork MPM.

php5-5.2.4_1PHP Scripting Language

mysql-client-5.0.45_1 Multithreaded SQL database (client)
mysql-server-5.0.45_1 Multithreaded SQL database (server)
p5-DBD-mysql50-4.005 MySQL 5.0 driver for the Perl5 Database Interface
(DBI)
php5-mysql-5.2.4_1  The mysql shared extension for php
php5-mysqli-5.2.4_1 The mysqli shared extension for php

I'm using vhosts to host 4 different websites with different domains.
The
sad part is that these all show no errors in their logs even with them
turned up to debug level. I've been looking at this off and on trying to
solve it as time allowed since mid-September. I'm completely stumped and
would appreciate any helpful suggestions where else I can look.

Thank you!

This email was sent to you by Reuters, the global news and information company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of Reuters 
Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters 
Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South 
Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Problem with Apache22

2007-11-01 Thread Philip M. Gollucci
>Peter Uthoff wrote:
>10:45:11  kernel: pid 66395 (httpd), uid 80: exited on signal 4 Oct 25

Can you provide either an strace or ktrace/kdump output from one of the
children.  Just attached to one let it die, then send the last 500 lines
or so of the output.

You probably have core dumps somewhere too -- a backtrace might be helpful.

Do you threading libraries match across the board for all software
(aka use ldd).

sysctls:
kern.sugid_coredump=1
kern.corefile=core.%N.%P

also,
cd /var/db/pkg ; /bin/ls -1 apache* php5* mysql* mod_*

>I don't believe the 'busy' message is accurate.
Correct.

>The sad part is that these all show no errors in their logs even with
>them turned up to debug level
Thats because the error is happening before the parent hands off the
request to the child.

This output might be helpful to others
cat /var/db/ports/apache22/options

Finally, Some snippets from the httpd.conf such as loaded modules and
other custom/non default things you have as well.



Philip M. Gollucci ([EMAIL PROTECTED])
o:703.749.9295x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Problem with Apache22

2007-11-01 Thread James
On 11/1/07, Peter Uthoff <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have a problem where my Apache procs are dying almost exactly every
> ten
> minutes as you can from the messages and web logs below:
>
> Oct 25 10:34:44  kernel: pid 66337 (httpd), uid 80: exited on signal 4
> Oct
> 25 10:35:33  kernel: pid 66357 (httpd), uid 80: exited on signal 4 Oct
> 25
> 10:45:11  kernel: pid 66395 (httpd), uid 80: exited on signal 4 Oct 25
> 10:55:21  kernel: pid 66340 (httpd), uid 80: exited on signal 4
>
> Looking at the Apache logs, I find the following:
>
> [Thu Oct 25 10:25:01 2007] [notice] child pid 66379 exit signal Illegal
> instruction (4)
> [Thu Oct 25 10:34:44 2007] [notice] child pid 66337 exit signal Illegal
> instruction (4)
> [Thu Oct 25 10:35:33 2007] [notice] child pid 66357 exit signal Illegal
> instruction (4)
> [Thu Oct 25 10:45:11 2007] [notice] child pid 66395 exit signal Illegal
> instruction (4)
>
> I tried upping the logs all the way to debug today and it really wasn't
> very helpful:
>
> [Wed Oct 31 15:59:19 2007] [debug] prefork.c(991): AcceptMutex: flock
> (default: flock)
> [Wed Oct 31 16:05:39 2007] [notice] child pid 73668 exit signal Illegal
> instruction (4)
> [Wed Oct 31 16:12:01 2007] [info] server seems busy, (you may need to
> increase StartServers, or Min/MaxSpareServers), spawning 8 children,
> there
> are 4 idle, and 17 total children
> [Wed Oct 31 16:15:04 2007] [notice] child pid 73779 exit signal Illegal
> instruction (4)
> [Wed Oct 31 16:15:28 2007] [notice] child pid 73717 exit signal Illegal
> instruction (4)
> [Wed Oct 31 16:18:37 2007] [notice] child pid 95939 exit signal Illegal
> instruction (4)
>
> I don't believe the 'busy' message is accurate. I think it's a result of
> the procs dying constantly as I just don't get that much traffic. I also
> have no idea what is causing the illegal instructions because none of
> the logs point out any specific detail to help me track it down.
>
> I'm running the following:
>
> FreeBSD 6.2-RELEASE-p8 FreeBSD 6.2-RELEASE-p8 #3: Thu Oct 25 20:04:14
> CDT
> 2007  :/usr/obj/usr/src/sys/GENERIC  i386
>
> apache-2.2.6_2  Version 2.2 of Apache web server with prefork MPM.
>
> php5-5.2.4_1PHP Scripting Language
>
> mysql-client-5.0.45_1 Multithreaded SQL database (client)
> mysql-server-5.0.45_1 Multithreaded SQL database (server)
> p5-DBD-mysql50-4.005 MySQL 5.0 driver for the Perl5 Database Interface
> (DBI)
> php5-mysql-5.2.4_1  The mysql shared extension for php
> php5-mysqli-5.2.4_1 The mysqli shared extension for php
>
> I'm using vhosts to host 4 different websites with different domains.
> The
> sad part is that these all show no errors in their logs even with them
> turned up to debug level. I've been looking at this off and on trying to
> solve it as time allowed since mid-September. I'm completely stumped and
> would appreciate any helpful suggestions where else I can look.
>
> Thank you!
>
> This email was sent to you by Reuters, the global news and information
> company.
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Reuters Limited.
>
> Reuters Limited is part of the Reuters Group of companies, of which
> Reuters Group PLC is the ultimate parent company.
> Reuters Group PLC - Registered office address: The Reuters Building, South
> Colonnade, Canary Wharf, London E14 5EP, United Kingdom
> Registered No: 3296375
> Registered in England and Wales
>
>
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> [EMAIL PROTECTED]"
>



First thing that comes to mind is to download knoppix and use either
"memtest" or "memtest86" as the cheatcode. I forget which.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Problem with Apache22

2007-11-01 Thread Ivan Voras
Peter Uthoff wrote:
> Hello,
> 
> I have a problem where my Apache procs are dying almost exactly every
> ten
> minutes as you can from the messages and web logs below:
> 
> Oct 25 10:34:44  kernel: pid 66337 (httpd), uid 80: exited on signal 4

Signal 4 is "illegal instruction", it might be caused by:

- corrupted executables
- executables built for processor architectures different than the one
used in the machine (e.g. built on one machine with CPU optimizations
turned on, then run on another)

> The
> sad part is that these all show no errors in their logs even with them
> turned up to debug level. I've been looking at this off and on trying to
> solve it as time allowed since mid-September. I'm completely stumped and
> would appreciate any helpful suggestions where else I can look.

Do you have any processor-specific instructions in your make.conf? How
did you install apache and other applications? Have you tried
recompiling apache and php without any optimizations?

Are you using PHP as mod_php? If so, you might want to try to switch to
fastcgi to isolate if the problem is in apache or php.



signature.asc
Description: OpenPGP digital signature


RE: Problem with Apache22

2007-11-05 Thread Peter Uthoff
ocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x28c44000,0x9000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x28c3f000,0x5000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x28c38000,0x7000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x28a0a000,0x15000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x28a1f000,0xeb000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x28b0a000,0x7000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x28b11000,0x2f000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x28b4,0xf8000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x289ef000,0xf000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x289c1000,0x8000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x289c9000,0x26000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x289b1000,0x3000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  munmap(0x289b4000,0xd000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  sigprocmask(0x1,0x280ba5c0,0xbfbfe4b0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  munmap(0x289fe000,0xc000)
 84893 httpdRET   munmap 0
 84893 httpdCALL  sigprocmask(0x3,0x280ba5d0,0)
 84893 httpdRET   sigprocmask 0
 84893 httpdCALL  close(0x13)
 84893 httpdRET   close 0
 84893 httpdCALL  close(0x5)
 84893 httpdRET   close 0
 84893 httpdCALL  close(0x4)
 84893 httpdRET   close 0
 84893 httpdCALL  exit(0)



 

-Original Message-
From: Philip M. Gollucci [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 01, 2007 4:29 PM
To: Peter Uthoff
Cc: freebsd-questions@freebsd.org
Subject: Re: Problem with Apache22

>Peter Uthoff wrote:
>10:45:11  kernel: pid 66395 (httpd), uid 80: exited on signal 4 Oct 25

Can you provide either an strace or ktrace/kdump output from one of the
children.  Just attached to one let it die, then send the last 500 lines
or so of the output.

You probably have core dumps somewhere too -- a backtrace might be
helpful.

Do you threading libraries match across the board for all software (aka
use ldd).

sysctls:
kern.sugid_coredump=1
kern.corefile=core.%N.%P

also,

Re: Problem with Apache22

2007-11-05 Thread Philip M. Gollucci
Which MPM did you use, if you didn't change it the default is prefork.

how about:
ldd /usr/local/sbin/httpd | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/libexec/mysqld | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/bin/php| egrep 'libthr|libpthread|libc_r'

ldd /usr/local/lib/libaprutil-1.so.2  | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/lib/libapr-1.so.2  | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/lib/mysql/libmysqlclient.so.15 | \
egrep 'libthr|libpthread|libc_r'

> WITHOUT_THREADS=true
So it looks like you don't want threads.  That makes things easier as
its the simpler case. At any rate, you'll want the output of all the
above to match.

Nothing in the ktrace/kdump jumps out at me.  Are you sure it crashed ?
(and you were attached to the correct httpd child)

httpd -X
and/or
httpd -DONE_PROCESS
might be helpful for that.




Philip M. Gollucci ([EMAIL PROTECTED])
o:703.549.2050x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: Problem with Apache22

2007-11-05 Thread Peter Uthoff
Yes, it's using prefork. I made no changes from the default install. The
results of ldd for each of these yielded "libpthread.so.2 =>
/lib/libpthread.so.2" in each case except for php and
libmysqlclient.so.15, which both returned nothing. Running apache in
debug, attached to the console resulted in output of "Bus Error" and
nothing else. The web logs showed no errors at all.

-Original Message-
From: Philip M. Gollucci [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 05, 2007 3:42 PM
To: Peter Uthoff
Cc: Philip M. Gollucci; freebsd-questions@freebsd.org
Subject: Re: Problem with Apache22

Which MPM did you use, if you didn't change it the default is prefork.

how about:
ldd /usr/local/sbin/httpd | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/libexec/mysqld | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/bin/php| egrep 'libthr|libpthread|libc_r'

ldd /usr/local/lib/libaprutil-1.so.2  | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/lib/libapr-1.so.2  | egrep 'libthr|libpthread|libc_r'
ldd /usr/local/lib/mysql/libmysqlclient.so.15 | \
egrep 'libthr|libpthread|libc_r'

> WITHOUT_THREADS=true
So it looks like you don't want threads.  That makes things easier as
its the simpler case. At any rate, you'll want the output of all the
above to match.

Nothing in the ktrace/kdump jumps out at me.  Are you sure it crashed ?
(and you were attached to the correct httpd child)

httpd -X
and/or
httpd -DONE_PROCESS
might be helpful for that.




Philip M. Gollucci ([EMAIL PROTECTED])
o:703.549.2050x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com 1024D/EC88A0BF 0DE5 C55C
6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.



This email was sent to you by Reuters, the global news and information company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of Reuters 
Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters 
Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South 
Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Annoying problem with apache22 / php5 - how to investigate?

2009-07-04 Thread Per olof Ljungmark

Hi,

We run 7-STABLE and apache22 with php5 serving pages from a webmail app 
(Horde).


Randomly (as it seems at least), there is a 500 (Internal server error) 
and a blank page is presented to the user like


[04/Jul/2009:15:19:37 +0200] "GET 
/services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -


There are no other messages in the logs, not even with LogLevel debug. 
The problem has survived several both OS and port upgrades and I really 
need to track this down now.


Question: What OS tools would be the best to further analyze this? 
Someone with more exparience running this combo perhaps would know?


Thanks a lot!

--
per

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Annoying problem with apache22 / php5 - how to investigate?

2009-07-04 Thread Bruce Ferrell


Per olof Ljungmark wrote:
> Hi,
> 
> We run 7-STABLE and apache22 with php5 serving pages from a webmail app
> (Horde).
> 
> Randomly (as it seems at least), there is a 500 (Internal server error)
> and a blank page is presented to the user like
> 
> [04/Jul/2009:15:19:37 +0200] "GET
> /services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -
> 
> There are no other messages in the logs, not even with LogLevel debug.
> The problem has survived several both OS and port upgrades and I really
> need to track this down now.
> 
> Question: What OS tools would be the best to further analyze this?
> Someone with more exparience running this combo perhaps would know?
> 
> Thanks a lot!
> 
> -- 
> per

I'd look in the Apache error_log

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Annoying problem with apache22 / php5 - how to investigate?

2009-07-04 Thread Per olof Ljungmark

Bruce Ferrell wrote:


Per olof Ljungmark wrote:

Hi,

We run 7-STABLE and apache22 with php5 serving pages from a webmail app
(Horde).

Randomly (as it seems at least), there is a 500 (Internal server error)
and a blank page is presented to the user like

[04/Jul/2009:15:19:37 +0200] "GET
/services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -

There are no other messages in the logs, not even with LogLevel debug.
The problem has survived several both OS and port upgrades and I really
need to track this down now.

Question: What OS tools would be the best to further analyze this?
Someone with more exparience running this combo perhaps would know?

Thanks a lot!

--
per


I'd look in the Apache error_log



I've looked, as stated above. Even with LogLevel debug there is not a 
trace. Likewise, I have E_ALL set in php.ini.


So, I need to dig deeper inte the workings of Apache with the aid of the 
right tools.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Annoying problem with apache22 / php5 - how to investigate?

2009-07-04 Thread Bruce Ferrell


Per olof Ljungmark wrote:
> Bruce Ferrell wrote:
>>
>> Per olof Ljungmark wrote:
>>> Hi,
>>>
>>> We run 7-STABLE and apache22 with php5 serving pages from a webmail app
>>> (Horde).
>>>
>>> Randomly (as it seems at least), there is a 500 (Internal server error)
>>> and a blank page is presented to the user like
>>>
>>> [04/Jul/2009:15:19:37 +0200] "GET
>>> /services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -
>>>
>>> There are no other messages in the logs, not even with LogLevel debug.
>>> The problem has survived several both OS and port upgrades and I really
>>> need to track this down now.
>>>
>>> Question: What OS tools would be the best to further analyze this?
>>> Someone with more exparience running this combo perhaps would know?
>>>
>>> Thanks a lot!
>>>
>>> -- 
>>> per
>>
>> I'd look in the Apache error_log
>>
> 
> I've looked, as stated above. Even with LogLevel debug there is not a
> trace. Likewise, I have E_ALL set in php.ini.
> 
> So, I need to dig deeper inte the workings of Apache with the aid of the
> right tools.


You're not looking at an Apache problem, but a PHP problem. 500 is the
error code for a failed CGI script/program. Try executing the php from
the command line.  i.e. Go to where ever
/services/portal/sidebar.php is and execute:

 ./sidebar.php httpclient=1

See what, if any, errors are thrown that way.

PHP is notorious for not sending good errors into the logs or to STDERR.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Annoying problem with apache22 / php5 - how to investigate?

2009-07-04 Thread Glen Barber
On Sat, Jul 4, 2009 at 8:54 PM, Bruce Ferrell wrote:
>
>
> Per olof Ljungmark wrote:
>> Bruce Ferrell wrote:
>>>
>>> Per olof Ljungmark wrote:
 Hi,

 We run 7-STABLE and apache22 with php5 serving pages from a webmail app
 (Horde).

 Randomly (as it seems at least), there is a 500 (Internal server error)
 and a blank page is presented to the user like

 [04/Jul/2009:15:19:37 +0200] "GET
 /services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -

 There are no other messages in the logs, not even with LogLevel debug.
 The problem has survived several both OS and port upgrades and I really
 need to track this down now.

 Question: What OS tools would be the best to further analyze this?
 Someone with more exparience running this combo perhaps would know?

 Thanks a lot!

 --
 per
>>>
>>> I'd look in the Apache error_log
>>>
>>
>> I've looked, as stated above. Even with LogLevel debug there is not a
>> trace. Likewise, I have E_ALL set in php.ini.
>>
>> So, I need to dig deeper inte the workings of Apache with the aid of the
>> right tools.
>
>
> You're not looking at an Apache problem, but a PHP problem. 500 is the
> error code for a failed CGI script/program. Try executing the php from
> the command line.  i.e. Go to where ever
> /services/portal/sidebar.php is and execute:
>
>  ./sidebar.php httpclient=1
>
> See what, if any, errors are thrown that way.
>
> PHP is notorious for not sending good errors into the logs or to STDERR.
>

Worse yet, this doesn't have to be a PHP problem... You can create an
.htaccess file containing 'FAIL' and it will generate an 500 response.


-- 
Glen Barber
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"


Re: Annoying problem with apache22 / php5 - how to investigate?

2009-07-05 Thread Per olof Ljungmark

Bruce Ferrell wrote:


Per olof Ljungmark wrote:

Bruce Ferrell wrote:

Per olof Ljungmark wrote:

Hi,

We run 7-STABLE and apache22 with php5 serving pages from a webmail app
(Horde).

Randomly (as it seems at least), there is a 500 (Internal server error)
and a blank page is presented to the user like

[04/Jul/2009:15:19:37 +0200] "GET
/services/portal/sidebar.php?httpclient=1 HTTP/1.1" 500 -

There are no other messages in the logs, not even with LogLevel debug.
The problem has survived several both OS and port upgrades and I really
need to track this down now.

Question: What OS tools would be the best to further analyze this?
Someone with more exparience running this combo perhaps would know?

Thanks a lot!

--
per

I'd look in the Apache error_log


I've looked, as stated above. Even with LogLevel debug there is not a
trace. Likewise, I have E_ALL set in php.ini.

So, I need to dig deeper inte the workings of Apache with the aid of the
right tools.



You're not looking at an Apache problem, but a PHP problem. 500 is the
error code for a failed CGI script/program. Try executing the php from
the command line.  i.e. Go to where ever
/services/portal/sidebar.php is and execute:

 ./sidebar.php httpclient=1

See what, if any, errors are thrown that way.

PHP is notorious for not sending good errors into the logs or to STDERR.



You're right, I will see whatever logging I can squeeze out from the 
script handling. It's really annoying it's an intermittent problem...


Thanks!
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"