While you working with web applications it could happen that you get several errors.. Never underestimate real server problems. When you try to start a new Web 2.0 application or just the usage and/or visits of your application increase, maybe non-linear, you can login to your application but you can’t proceed.
On enterprise applications it’s recommended to set
php display errors to off, so won’t see what really happened.
While tracking the problem to your browser and the customers and may the service provider, you should just login with a shell.
First thing you should do is, like all time, who and last. After that, may you try to find out what happen in the apache access and error log. You will find nothing, cause there is nothing critical, nothing new. May you see the session file in your filesystem, but why is it empty? A php bug?
Why? Ok just the answer, try this:
df -h , you will see the a 100% full partition and when you try a
du -shm /var/log/* you see your problem… GB’s of apache logs…
What happened? Your Web 2.0 application uses polling, and your apache got a custom, combined log which writes to access.log.
Solution 1: Drop the line in your apache virtualhost configuration for custom, combined log
Solution 2: Proceed a massive logrotation
Solution 3: Pipe the combined log to a perl or php-cli script which filters the polling events (I prefer)
On local, staging and or development installations you should switch the display errors for php to on,… then you get messages like this:
WARNING: session_write_close() [function.session-write-close]...