Re: [Phpgroupware-users] Logs messages, session and addressbook problems with 0.9.16

[Chris Weiss]

I've heard in the ##php channel that apache 2.2 and php stilll have
some issues to work out.  some people run it with no problems, others
have problems.  phpgw has not been tested in this configuration so I
can't speak for it's stability.  it's possible that your header error
is related to this.

is the header error new since filling tmp or did it always do this?
did you restart apache after clearing out tmp?  there may be open
handles or something.

how much temp space depends on what you do with phpgw and how activer
the users are.  if you have "phpgw info array" cache on (see
Admin->site config) this session files will be notably larger, and the
more apps you have enabled the larger it will be.  at one time emails
were cached in the sessions too, but I think they are just cached in
the database now.  I can't really make a size recomendation since my
sites are quite low usage (2-5 users at a time).  database session, in
some tests we did some years ago, had very little perfomance impact.
the biggest benifit would be if you wanted to scale to a web server
farm, the sessions would then be accessable from all web servers in
the farm via tha database master wihtout using NFS.

what sql server are you using?  addressbook does not have good indexes
on all db's yet.  some tweaking might be needed, there might also be
some info in the list archives and/or bug reports.

On 8/10/06, Anthony Chavez <address@hidden> wrote:
> Hello, phpgroupware-users!
>
> I have the following environment:
>
> phpGroupWare    0.9.16
> PHP             5.1.4
> Apache          2.2.2
> FreeBSD         6.0-RELEASE-p4
>
> I have been recently made aware that PHP 5 is currently not supported
> by phpGroupWare, but we've had good luck with it until now, and we are
> not in a position to downgrade to PHP 4 just yet.
>
> I understand that running the CVS version of phpgw is the preferred
> course of action for people that have problems, but I thought that I'd
> at least pose these questions before I upgraded. ;-)
>
> 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?
>
> 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."
>
> However, after doing so and long after the session.gc_maxlifetime
> (3600) has expired, users are still unable to login, unless they do so
> From a different machine.  I didn't bother making a backup, because
> temp directories are supposed to be just that: temporary, right?
>
> I've noticed the following in syslog.  Earlier this morning, it was occuring
>
> httpd: PHP Warning:  mcrypt_generic_deinit() [<a 
> href='function.mcrypt-generic-deinit'>function.mcrypt-generic-deinit</a>]: Could 
> not terminate encryption specifier in 
> /usr/local/www/data-dist/phpgroupware/phpgwapi/inc/class.crypto.inc.php on line 110
>
> I'm also seeing, e.g., "account loginid 'acc' is expired" in the
> phpgw_log table.
>
> My thought is that the session ID is being referenced in the database,
> but because it does not exist in the temporary directory, the login
> fails.  But the problem persists even after deleting any and all
> cookies (related or not) for this particular site from my browser.
> How can I resolve this?
>
> I have also been told that 128MB is probably not sufficient for very
> many users.  How much disk space should I expect for sessions?  Should
> I consider using DB-backed sessions for a large number of users?
>
> 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.
>
> Any help would be appreciated!
>
> --
> Anthony Chavez                                 http://anthonychavez.org/
> mailto:address@hidden         jabber:address@hidden
>
>
> _______________________________________________
> Phpgroupware-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/phpgroupware-users