I copied the front-end files for Agenda from the lang02 account to the lang account, checked the permissions were identical and a select sample of the actual files were identical.

The instance on lang02 works fine, except when there is a conflict with a current session from the lang account - in which case a php Warning of access denied to the session tmp file on the server appears on the page. The occasional problem is likely due to reuse of session variables arising from testing, and unlikely to occur in normal use - the lang02 instance hasn't failed before.

The instance on lang is suffering from something else: the index file includes a login file which creates a new session, logs in to the database, authenticates the user and populates the session array, then calls the agenda.php page. The agenda.php calls new session and creates a new db object (just as the instance in lang02 account does). However the difference is that the SESSION array has no values in the lang account, but does in the lang02 account. With no SESSION values, virtually none of the GUI of the agenda page is displayed.

After much testing and conversations with Clifton, I wrote to sys-admins to see if they could report anything about the lang account that might explain its behaviour, or anything about the php service that might explain any of the behaviour we're getting.