(last edited on April 29, 2014 at 1:29 am)
There’s a feature in PHP called Sessions that allows a bunch of web pages to share the same variables; ordinarily, they’re lost between each page access. This is a cool thing to be able to do, allowing one to create web applications a little more easily. The only reason I know about them at all is because today WordPress wouldn’t let me log in, reporting the following (edited) error:
Warning: session_start(): open(/tmp/sess_xxx, O_RDWR) failed:
Permission denied (13) in /.../wp-hashcash.php on line 22
I checked out the file in question, and it was written by user nobody instead of myself. Therefore, wp-hashcash.php couldn’t start the session, and I got error messages all over the place when I tried to login. I couldn’t do a damn thing.
Then I read in the documentation that sessions were tied into browser cookies, so I looked in my cookie cache and saw an entry called SESSID that matching the file being complained about. I deleted that cookie, and could login again. Problem solved. This cookie contained the session information that was causing PHP to puke, so deleting the cookie forces the session to close.
An annoying but educational detour.
2 Comments
Actually (at least with the hosts I’ve used) all PHP processes are created by [nobody], not by [your user], because the server runs only a single module that processes everybody’s accounts (I am assuming you are on a virtual server). This has caused problems for me in the past when I have uploaded a file as [my login], and tried to modify it in PHP later as [nobody] and it wouldn’t work.
That said, I don’t know what ultimately caused your problem, perhaps your browser closed down before it has finished writing to your last session cookie or something. Resetting the cookie was the right move.
My guess is that, even with it working, you can go back into the server and find that your session file is written by [nobody].
——-
Yah, ordinarily that would be the case, except I’m running PHP on my host as a FastCGI module under my own username, precisely because I *do* want control over files that are written. This is primarily for development reasons when I was writing LZIL, as I was dynamically creating PHP thumbnails on the fly and writing them.
It’s kind of slow and sucky to use FastCGI, even though the host people claim it’s supposed to be just as fast (and yep, it’s a virtual server). Most of the session files are written to /tmp under my own username…this I did verify yesterday. Why that single session WASN’T written that way is anyone’s guess…I’m thinking that either there was a hiccup somewhere that caused my processes not to run that way…maybe they were reconfiguring PHP globally and it temporarily ignored .htaccess directives for a few hours before they caught it.