On Mon, June 11, 2007 8:36 pm, Mattias Thorslund wrote: > One of my clients just received a PHP warning that session_destroy() > failed. Using the default session handler (with tmp files), what are > the > most likely things that can cause session_destroy() to return false? > > Thanks for any suggestions. Several things spring to mind... root user decided to wipe out /tmp root user re-defined where /tmp was, for a new hard drive or performance or... root user mounted something else on /tmp for a moment (or longer) hard drive actually failed /tmp was "full" and some automated process nuked oldest /tmp files If the same user was surfing with 2 tabs open, and the session was locked by the second tab, and the first tab tried to destroy it... I think it is possible that PHP *might* be unwilling to wait "too long" for the session file to be unlocked so it can be unlinked... This is just a theory. You'd have to read PHP source to find out for sure, or conduct controlled tests. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
