[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-users] Apache/PHP problems was Problems with Apache Pr

From: Bart Bailey
Subject: Re: [Phpgroupware-users] Apache/PHP problems was Problems with Apache Processes
Date: Tue, 16 Sep 2003 17:14:34 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

My current setups include:

Distribution: RedHat 8.0
Kernel Version: 2.4.18-26.8.0
Libc: glibc-2.2.93-5
Patches/Custom: None
Apache: 2.0.40
PHP: PHP-4.2.2-8.0.7
Database: PostgreSQL 7.2.3-5.80
Number of Users: 250
Avg Concurrent Users: 25

Distribution:  RedHat 9.0
Kernel Version: 2.4.20-19 SMP
Libc: glibc-2.3.2-27.9
Patches/Custom: None
Apache: 2.0.40-21.3
PHP: PHP-4.2.2-17.2
Database:  PostgreSQL 7.3.2-3
Number of Users: 5
Avg Concurrent Users: 1

Distribution: RedHat 9.0
Kernel Version: 2.4.20-18.9
Libc: glibc-2.3.2-27.9
Patches/Custom: None
Apache: 2.0.40-21.3
PHP: PHP-4.2.2-17.2
Database: MySQL 3.23.56-1.9 / PostgreSQL 7.3.2-3
Number of Users: 2
Avg Concurrent Users: 1

I had previously been using phpGroupWare and had not notice the problem, however, I upgraded Apache, my kernel and glibc just prior to moving to

A couple of quick questions:
Does this mean there are two problems instead of just one? The calendar application not storing the preferences in the correct format, and/or Apache/PHP not terminating the script after an alotted amount of time?

Also, in tracking down the formatting(intval(0)) problem, any clues to where I should be looking? In the calendar scripts or in the phpgwapi preference scripts? Thanks,

Alex Borges wrote:

I think most with a (largish) install have experienced this. I know i
have. And we need to hunt it down.

For example, in previous versions of the email app (pre cache on db),
when you viewd a message, deleted it, then click the back button  would
lead to this state (apache goes mad).

Now there is also this excelent calendar report (bellow), that also
points to what appears to be the same problem.

Now, php has a timeout for execution of scripts, so in any case, those
proceses should die when that time is over.

This points to a bug in the php version, or the apache version, or a
combination thereoff. Maybe even to lower level libraries (ive allways
thought this was an email/socket related problem in php. Probabbly
because the same bug shows  in squirrelmail (which doesnt even use the
imap library), i can confirm this for a 12000 user install of SM).

So, all of the ppl that have gotten this ugly bug, please post your
apache/php/db combo bellow, versions included, prefferably distribution
version, kernel version and libc version quirks/patches you may have
applied. Lets see if we have a pattern somewhere.

El lun, 15-09-2003 a las 16:44, Bart Bailey escribiĆ³:
On September 10, 2003 Jorge Izquierdo posted a message about problems with the apache processes. He was experiencing httpd processes consuming all of the CPU on his system. I am having a simular problem. An associate of mine tracked the problem down to the calendar program.
My associate is using RH9.0/MySQL, sorry but the other details are unknown.

It works like this:
In user preferences, if a user selects 00:00 hrs as a workday start or work day end, viewing the day view causes the error. If the start preference is changed to 01:00 and the end to 23:00 the problem goes away. I have tried several different combinations of times, and the problem only seems to arise if 00:00 hrs is selected.

I have tried this on 4 separate phpGroupWare instalations( 3 with Postgresql and 1 with MySql), all have the same problem. Additionally, changing the persistant connections in the php.ini seems to have not effect.

Changing the Forced Preferences doesn't seem to fix the problem if the user selects 00:00 as a work time.

I have looked at the class.uipreferences.php in the calendar directory, but I am unsure where to make changes to the code to fix the problem. Any help??

Thank You,
Bart Bailey

Phpgroupware-users mailing list

Phpgroupware-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]