top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Saving session to database

0 votes
848 views

I'm having a problem with webtrees ... http://webtrees.net/
My copy is running on http://webtrees.lsces.org.uk and you will see that it is throwing an error relating to the session handling.

Running Apache 2.2.22, PHP5.4.14, MySQL 5.5.31 ( http://lsces.org.uk/phpinfo.php )

If I comment out the session_set_save_handler() section of session.php then I can log in and use the site. Have tried reworking that as a SessionHandlerInterface without any success. As far as I can see, the 'write' function of the handler is not being called and while there are various notes about problems with PHP5.4 blocking access to the write and close functions, none of the fixes I have tried have resulted in a working setup.

Anybody seen this problem with PHP5.4?

http://lsces.org.uk/hg/webtrees/file/dcf6ff358108/includes/session.php#l334 is the code that seems to be failing.

posted May 16, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

4 Answers

0 votes

What error do you get? I tried loading the site but it shows up fine. In general, you should post the error message for two reasons:
1) Most people don't bother to open a (terrible slow) website.
2) Archives, so if anyone after you comes up with the same problem, he will be able to refer to the archives to find his solution.

answer May 16, 2013 by anonymous
0 votes

Been working on this most of the morning without success :( Faulty version is back up, and showing all the error messages, but basically ...

ERROR 2: session_regenerate_id(): Session object destruction failed 0 Error occurred on in function session_regenerate_id. But I think it's the initial session write that is failing

ERROR 2: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php5) 0 Error occurred on in function session_write_close

But it should be writing to the database not the file directory.

answer May 16, 2013 by anonymous
It seems to me the session functions are failing, probably due to problems with the database. Have you checked that there actually is a ##session table in your database?
You might want to add some debugging code to these functions, to check if errors occur with inserting or retrieving the sessions from the database.
Well past that stage without making any progress. Using the write function outside of the session_set_save_handler() it works perfectly, and then the read can see the saved sessions and can load them.

I am convinced that something is wrong with the general setup which is preventing the write and close from firing when it should. I can not trace any attempt to call the write function in the session handling.

I'm currently checking out the adodb-session handler which WAS working in PHP5.3 but seems to be showing similar problems in PHP5.4
0 votes

Well, I'm not sure what would be the problem here, but some general comments:
There have been various changes in session handling between 5.3 and 5.4, so most likely it is in there. Check if there are any references to register_shutdown_function, and replace them with session_register_shutdown.

Second, check the return value of session_set_save_handler, it is a bad habit not checking return value of a function, just because it works. If that doesn't help, take the session piece out of the big framework, and
test it in a separate file. If that also fails, you've got a small piece of code you can post here which will encourage others to have a look at it at their box.

answer May 17, 2013 by anonymous
0 votes

I've found database session storage requires extra diligence in error handling. When I see that error at 0 it is usually because something blew up either before the session handler was ready or after it was torn down.

answer May 17, 2013 by anonymous
Similar Questions
+10 votes

I want to save a password in encrypted form, so that it will not be understand by human. Is it possible ? If yes then please explain briefly.

+1 vote

I've two machines set up with Apache2.4 and PHP5.4.15 and I'm trying to debug owncloud as it has problems with Apache2.4. This autoloader and routing 'fun' seems totally over the top, and is failing without giving any errors, but the question is "what limits the amount of text displayed using print_r() ?" Where I drop in a print statement causes crashes, but when working I'm not getting a complete printout. One machine is clipping at around 4500 characters, while the other is managing around 9000, and neither is displaying the 'TAG' labels after that block.

It's not something I've seen before ... I've been using this method for many years and normally see all the text. So can anybody throw light on why this may be happening now? Interestingly the two machines are giving different problems with this application which works correctly on Apache 2.2

0 votes

Anybody have phpdocumentor running with PHP5.4? I'm convinced that the errors my copy is throwing are due to e_strict, but I've confirmed that I have the right ini file ( all the needed extensions load ) and I'm getting error_reporting showing 22527 with e_strict off and 24575 with e_strict on - so at least it is changing the setting?

Once again I'm wasting hours getting something which I have had running fine on the older servers to actually work in a new setup. In this case phpdocumentor seems to suggesting *IT* needs PHP5.3 but the main script also switched e_strict off anyway, so 5.4 should work as well?

...