I have an application I’ve written in PHP from scratch. I’m using PHP’s native session handler functions for handling user authentication and persistence.
When testing on the development server, everything is peachy. Authentication, persistence, etc, works fine.
When installed on the production server, everything works fine up until the user authentication — when the app actually writes data to the session object, suddenly the HTTP request that follows it completely hangs exactly when session_start() is executed.
I suspected the temporary session files were being locked by PHP and never released, so I tried following up the spots where the app is writing to the session object with session_write_close(), but that didn’t seem to have any effect.
Does this sound like a file lock issue or is this something else? I’m confused on why session_write_close doesn’t seem to be taking care of the file lock issue if that’s the case, which is why I’m wondering if there could be something else at play here.
Any possible thoughts or ideas?
Reply to Pekka’s great suggestions:
- The production server is a linux environment. phpinfo reports
Linux wynn 2.6.18-164.9.1.el5PAE #1 SMP - The page is not calling itself
- I can read/write the session folder and files. I can see the authentication data that gets serialized into the files from the auth attempt.
Just a few ideas – in addition to pygorex’s comment to first turn up the error_reporting, which should definitely come first.
Probably not it, but there are three hangups described in the User Contributed Notes to session_start:
When using /dev/random as session entropy file
When page is calling itself with the same session
On Windows
Can you read your session cookie and check whether a session file of that name exists in your /tmp directory? Is that file writable? Does it contain data?
If all else fails, the manual page on session_save_handler() has what seems like a full custom replacement for the default session handling functions. Consider using those for detailed debugging.