yes, before we disable any PHP module, we want to be careful to only do it only if necessary since it under production
On Sat, Dec 19, 2009 at 6:55 AM, Justin Pasher <just...@newmediagateway.com>wrote: > gary lim wrote: > >> Hu justin, >> >> 1. Because its a production site, we are unable to disable the PHP >> modules/script......From the log output below, we are having difficulty to >> pinpoint the source of error. I just spent the last couple of hours to run >> through the pages and see if the log shows up any systematic >> error...unfortunately, wasn't able to replicate the source of problem >> causing the glibc issue. Not sure if this only happen during high >> loading.... >> > > I knew you would say that, but that doesn't change what I suggested. It's > like the situation where someone has suspected flaky hardware (e.g. bad > RAM), but they can't reboot the server to run memtest86 because it's > production. It won't get you any closer to a solution when you can't test > all possible avenues, especially when it's very difficult to even replicate > the issue consistently. > > -- > > Justin Pasher > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > " from the digest: users-digest-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
