I've had this issue a few times now. Once I even fixed it; but I'm getting the impression the fix I've implemented other times was impermanent. Overview:
On going to my OPAC page, I get the following errors on the top of the page:
Warning: session_start(): open(/tmp/php/data/sess_9e2c0eee8199af6a832be4cf8f25caa1, O_RDWR) failed: No such file or directory (2) in /var/www/openssl/openbiblio/shared/read_settings.php on line 131
Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /var/www/openssl/openbiblio/shared/read_settings.php:131) in /var/www/openssl/openbiblio/shared/read_settings.php on line 131
I overcame this issue last time by creating /tmp/data/php. I've got no idea why but once in a while I guess I lose this directory. Interestingly, that isn't working this time.
I've got my installation online at https://oelns.dyndns.org/openbiblio/opac/index.php - in case one wants to observe this for themselves. I'd be grateful for any input on this..
You seem to have CSS turned off.
Please don't fill out this field.
Oh, this is on Fedora Core 1, OpenBiblio 0.4.0
Odds are there's a cron job that cleans out /tmp and is deleting the directory. If I were you, I would make a directory for sessions outside of /tmp and change php.ini to point to the new directory. Another method would be to find the script that cleans /tmp and tell it to leave /tmp/php/data there.
I would venture to guess that it's tmpreaper that's doing the cleaning, but I don't use Fedora, so I'm not sure. If it is tmpreaper, though, you could create a file in /tmp/php/data that is unwritable (or immutable, if you prefer). Tmpreaper won't delete that file, and because it exists, it won't delete the directory. See tmpreaper(8).
In a future release (probably the next one, but...) we're planning to move the session data into the database to eliminate this whole class of issues.