[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-users] Re: Logs messages, session and addressbook problems
[Phpgroupware-users] Re: Logs messages, session and addressbook problems with 0.9.16
Thu, 10 Aug 2006 16:57:44 -0600
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin)
Anthony Chavez <address@hidden> writes:
> Hello, phpgroupware-users!
Hello again, and here is an update on my progress.
> I have the following environment:
> phpGroupWare 0.9.16
> PHP 5.1.4
> Apache 2.2.2
> FreeBSD 6.0-RELEASE-p4
> My first question involves the following syslog message.
> httpd: PHP Warning: Cannot modify header information - headers already sent
> in Unknown on line 0
> This is repeatedly logged, even with output_buffering = on in php.ini,
> but doesn't tell me much. What could be causing this?
I'm currently in the process of configuring my machine to serve both
PHP5 and PHP4 from 2 separate httpd processes (quite a task in and of
itself). I'm hoping that moving phpgw to PHP4 will correct this
> We are also experiencing 2 issues.
> The first is this. Early this morning, our 128MB temporary directory
> (an mdmfs(8) MD_SWAP disk) ran out of free space, and users were no
> longer able to login. My initial reaction to this was "flush the temp
> directory and sessions will be re-created."
After much effort, I finally caved in and dropped the database,
re-created it, and reconfigured from scratch. This solved my problem,
but we lost some user data (calendars, etc.). Fortunately, my users
were made aware ahead of time that this was a deployment solely for
evaluation purposes, so they kept backups.
Nevertheless, I would be *very* interested in knowing what to do in
case this should happen again. I would prefer to store session
information in swap space (or better yet, an MD_MALLOC disc), but
doing so imposes a relatively low ceiling on what I can store therein.
It would be good to know how I could manage this more effectively.
> The other issue is in regard to the addressbook module. After adding
> a contact into the addressbook, loading the module in a browser takes
> at least a full minute to load in the user's browser.
> My hypothesis here is that for some reason the database session is
> hanging (due to bad SQL or something similar) until it hits some
> timeout, where it is forced to respond. Nothing shows up in the logs,
> but a sockstat(1) shows that the connection does persist until
> approximately the time that the page finally displays.
This issue is still open.
I am seeing a new (or I may just have overlooked it previously) syslog
httpd: PHP Fatal error: Maximum execution time of 60 seconds exceeded in
I'll be diving into the source soon, but I need to get PHP 4 and 5
working first. Something tells me that this is indeed a malformed
P.S.: HEAD would not permit me to login. I'm writing this off as an
issue with PHP5, and will try again later.
Anthony Chavez http://anthonychavez.org/
Description: PGP signature