session handling issue
Goto page 1, 2  Next
 
Post new topic   Reply to topic    34SP.com Forum Index // Scripting Support
View previous topic :: View next topic  
Author Message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Wed May 14, 2014 5:59 pm    Post subject: session handling issue Reply with quote
I am using a custom PHP session handling class with database storage to test a login procedure. The session stuff is working as it should most of the time. At apparently random intervals (anything from a few days to a couple of weeks), I am receiving the following error message:

Warning: Unknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

This continues for an hour or so, then normal service is resumed. Any suggestions?

Update 27th June

If you have this hosting setup:
PHP Version 5.4.xx
suhosin Extension 0.9.34-dev
MySQL/mysqli 5.1.59

and you are considering using custom session handling which writes session data to a database, you may have issues.
The sessions are periodically trashed by PHP/suhosin.

The solution offered by support to my problem (despite a fix being available Fix saving sessions in PHP 5.4 with user session handlers (fix #12)) is this:

Quote:
In general, saving the sessions in the database isn't great. It is not really designed for that purpose and MySQL serves as a very poor tool for session storage, locking being a key issue - not to mention no built-in support for purging. There's also the fact that this is a shared server and adding this kind of load to the database if the site gets busy will lead to more troubles. Please do try to store them on the file system and let us know there's any further session troubles.


Continue reading through this thread only if you are a chronic masochist...

Update 28th June:
the solution above, it now seems, was a temporary measure; since then, a modification/patch has been applied to the suhosin extension, and 18hrs on from that surgery, the custom session handler appears to be holding up without being held up.

I am hopeful that support has resolved the suhosin (ft.PHP) v custom_session_handling conflict, and that I'm not terminally delusional.

Update 1st July

The patch appears to be a stable resolution to the issue; I have enjoyed error-free session handling since it was applied, and I'm hopeful that this will prove to be my last post relating to this problem. However, I remain terminally delusional with regard to every other aspect of my life, whether virtual or otherwise...


Last edited by lauradoom on Tue Jul 01, 2014 7:05 pm; edited 3 times in total
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Mon May 26, 2014 3:59 pm    Post subject: Reply with quote
Replying to myself--always a good omen in a support forum.
Situation as above. The custom session handling class, together with session_start() appears at the top of each page, with no intervening modifications. The only indication of a problem is the message above, both on the displayed page and in the error log.

How am I supposed to diagnose a problem in 'Unknown' on line 0?

I have searched for this warning and have, with one exception, found this to be an issue only with regard to 'session data (files)'. The exception was a page which obviously is experiencing the same problem, the warning being the only content displayed.

If this was a 'live' site, I suspect that I would not be asked by users for a hosting recommendation, particularly as this problem appears to be out of my control i.e. due to an intermittent server issue for which I can find no resolution.

I would be insufferably grateful to receive an alternative explanation--some practical advice or suggestion I can work with.

Thanks in advance (though I'm not holding my breath).
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Tue May 27, 2014 11:13 pm    Post subject: Reply with quote
Same issue tonight around 23:00. I guess I'll log each occurrence here until someone can explain why PHP sporadically decides it wants to write sessions to file despite the presence of a custom session handler.
Back to top
View user's profile Send private message
philr
Super Member
Super Member


Joined: 05 Nov 2003
Posts: 990
Location: Exeter

PostPosted: Tue May 27, 2014 11:34 pm    Post subject: Reply with quote
I'm just guessing, but maybe your session data is getting screwed up whenever the server is restarted.

You can find out when the last reset happened by running uptime from the command line. Or if you don't have shell access, try running this PHP script from your web space:
Code:
<?php
passthru("uptime");

_________________
Phil Ronan
フィリップ・ローナン
Back to top
View user's profile Send private message Visit poster's website
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Wed May 28, 2014 2:53 pm    Post subject: Reply with quote
Thanks Phil--I appended that piece of code to a 'mess-with-stuff' script, and it returned the following:

15:12:03 up 51 days, 5:02, 0 users, load average: 2.87, 2.87, 3.00

which suggests that it's not an Apache issue?
0 users? Unsure as to what that refers.

Meantime--breaking news. I finally received a relevant error message today (having been pondering the upside to setting the error-reporting stuff)...

Warning: mysqli::mysqli(): (HY000/2003): Can't connect to MySQL server on '127.0.0.1' (110) in /var/www/vhosts/path_to/hand.php on line 12

which is in the __construct element of the handler class where it creates a 'new mysqli()' connection.

If this indicates a MySQL server problem, I wonder why it persists for an extended period (one or two hours) and happens on a (consistently) irregular basis.
Back to top
View user's profile Send private message
philr
Super Member
Super Member


Joined: 05 Nov 2003
Posts: 990
Location: Exeter

PostPosted: Wed May 28, 2014 6:57 pm    Post subject: Reply with quote
That means the server OS (i.e. Linux) hasn't been restarted for 51 days. Finding out when Apache and MySQL were last restarted is a little bit trickier, as it depends on how your system is configured.

If your Apache error log exists in the same place as on my server, this script will tell you when the last 5 Apache restarts took place:
Code:
<?php
header("Content-Type: text/plain");
passthru("cat /var/log/httpd-error.log |grep resuming |tail -n5");


And as far as I know, the only way to tell when MySQL last restarted is to check the date stamp on the MySQL sever's PID file. (Again, this is very system-specific and won't work unless your MySQL files are stored in the same location as on my server.)
Code:
<?php
header("Content-Type: text/plain");
passthru("ls -al /usr/db/mysql/*.pid");

_________________
Phil Ronan
フィリップ・ローナン
Back to top
View user's profile Send private message Visit poster's website
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Wed May 28, 2014 10:04 pm    Post subject: Reply with quote
I ran those two passthru functions but both blanked which, in my blissful ignorance, suggests to me that the files are elsewhere.

I'm on prohost33--I don't see any log files in (or under) the var/usr directories, nor in 'statistics' (beyond net access & error), though that could be down to pre-senile myopia on my part.

Are these logs available to everyone on hosting packages? I may do some searching and play around with possible locations based on server variations.

Thanks for your help Phil...
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Fri May 30, 2014 1:49 pm    Post subject: Reply with quote
It's back:

[Fri May 30 14:41:48 2014] [error] [client 82.8.237.122] PHP Warning: mysqli::mysqli(): (HY000/2003): Can't connect to MySQL server on '127.0.0.1' (110) in...

I now have a file logging procedure in my handler class __construct function, which will give me a physical record of instances where the MySQL server is unavailable (though only at those times when I am here and attempting to connect--access to MySQL server uptime data on prohost33 would be preferable, if only to fully appreciate the unreliability of this hosting package 'service').
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Sat May 31, 2014 6:31 pm    Post subject: Reply with quote
Haven't had this much fun since my biological mother became a permanently high priestess.

The meaningful error messages began when I assigned the handler functions
Code:
session_set_save_handler($this, true);
before instigating the logging procedure in the __construct() function. This seemed to work well:

30-05-14 15:21:16 construct: Can't connect to MySQL server on '127.0.0.1' (110)
30-05-14 14:52:23 construct: Can't connect to MySQL server on '127.0.0.1' (110)
30-05-14 14:52:10 construct: Can't connect to MySQL server on '127.0.0.1' (110)
30-05-14 14:51:40 construct: Can't connect to MySQL server on '127.0.0.1' (110)
30-05-14 14:41:48 construct: Can't connect to MySQL server on '127.0.0.1' (110)
28-05-14 16:22:08 construct: Can't connect to MySQL server on '127.0.0.1' (110)
28-05-14 16:17:59 construct: Can't connect to MySQL server on '127.0.0.1' (110)

until shortly after editing my last post (above) offering the logging update.

Now it seems I'm back to the anonymous warnings only, on displayed pages and in the logs--nothing in my custom error log, though the handler class has not been modified since:

[Sat May 31 18:47:49 2014] [error] [client 82.8.237.122] PHP Warning: Unknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

after a series of these:

[Sat May 31 15:34:06 2014] [error] [client 82.8.237.122] PHP Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in /var/www/vhosts/path_to_/logout.php on line 10, referer: http://www.domain.net/path_to/page2.php
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Sun Jun 01, 2014 10:30 pm    Post subject: Reply with quote
48 hours + of trying and testing, and this is all I am getting:

Warning: Unknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

So, what did you all do with your weekends?
Back to top
View user's profile Send private message
philr
Super Member
Super Member


Joined: 05 Nov 2003
Posts: 990
Location: Exeter

PostPosted: Tue Jun 03, 2014 12:22 pm    Post subject: Reply with quote
Hi, sorry to hear you're still having problems.

It looks like you've got a server configuration problem now. The "Failed to write session data" error usually means that PHP is trying to save the session data in a folder for which it doesn't have write permission. (Either that or the folder just doesn't exist.)

Try putting passthru("ls -al /var/lib/php/session"); in a PHP script and see what you get.
_________________
Phil Ronan
フィリップ・ローナン
Back to top
View user's profile Send private message Visit poster's website
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Fri Jun 06, 2014 9:47 am    Post subject: Reply with quote
Definitely exists, and is writable--I guess you can imagine what it churned out--but nothing relating to my domain, which (given the error/warning message) would not be surprising if it related to Failed to write session data (files).

Failed to write session data (user) is surprising--user acknowledges that the default session handling process (files) has been overridden, which in turn suggests that the custom session handling class (as invoked by the
Code:
session_set_save_handler()
function) has been recognised.

As it is, the message is distinctly generic (more oxymorons as and when available). Yesterday, sessions were intact--today I'm back in errorLand...

Thanks again Phil
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Sun Jun 08, 2014 10:25 am    Post subject: Reply with quote
Breaking news: sessions have not been broken for over 48 hrs.
I mailed support about this issue; they changed the default location for session files, which was, I guess, the only practical option, given the nature of the error message.

While no definitive cause and effect has been established, there does appear to be a correlation between session.save_path and custom session handling, even when data is being saved to a database. The native handler functions are designed to accept particular arguments, whether or not these are used by the custom methods in the class. One of the arguments, to the open() function, is $save_path, and a value is passed whenever the class instance is initiated. It's possible that PHP verifies the validity of that path (file exists/is_writable) when the write() method is called internally--at script end or when session_write_close() is called--and suffers a seizure if the check returns false even when the value is irrelevant to the writing method employed. Does that seem counter-intuitive? Probably not, unless (like me) you're irrational, dysfunctional, and drift through life in a semi-comatose fugue state--on a good day.

Flaking news: (@Phil) I tried to post a reply here on the day you offered that last passthru() stuff, but was blanked by a 403. Predictably, my first over-reaction was conspiracy theory. From there I shifted to assuming that oxymorons had been interpreted as a form of abuse. Finally I forced myself to think rationally--and imploded. On recovery, I identified the cause: wrapping phrases in single quotes, resolved by removal and formatting in italics. 2nd millennium filters? Punctuation overload? Maybe a precaution for readers offended by the visualization of text as spoken and accompanied by the finger-dance of sardonic speech marks?

I sense the onset of yawnfest, so thanks Phil, for pragmatism and rationality {|:>) and to support@34sp for alleviating my innate helplessness...
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Sun Jun 08, 2014 9:47 pm    Post subject: Reply with quote
Why did I say that? Last few hours have seen the return of...

Warning: mysqli::mysqli(): (HY000/2003): Can't connect to MySQL server on '127.0.0.1' (110)

and it's Sunday, so no response from support by email, and presumably no-one present, awake and monitoring errors on servers(?). Obviously nothing on the server status page--but it could be worse; I might, on a bad day, have resorted to cynicism...
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Tue Jun 17, 2014 5:49 pm    Post subject: Reply with quote
I would like to post this update confirming that the modification of the default session.save_path has resolved this issue--but I can't.

Neverthemoreorless, thanks to Thibaut for persisting in the quest for session handling integrity.
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Mon Jun 23, 2014 9:44 pm    Post subject: Reply with quote
My first post was 14th May. It is now 23rd June. Support has tried changing default session.save_path to a directory within my httpdocs, and modified my handler in an attempt to catch the error. My error logging routine within the handler consistently fails to register any errors. I continue to appeal to an unpopulated forum for assistance. Meantime:

PHP Warning: Unknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/vhosts/my_domain/httpdocs/tmp) in Unknown on line 0
Back to top
View user's profile Send private message
philr
Super Member
Super Member


Joined: 05 Nov 2003
Posts: 990
Location: Exeter

PostPosted: Tue Jun 24, 2014 6:05 pm    Post subject: Reply with quote
Clutching at straws here, but if your server has been updated to PHP 5.4 and includes the suhosin security patch, then perhaps this is relevant:

http://www.simplemachines.org/community/index.php?topic=486606.0
_________________
Phil Ronan
フィリップ・ローナン
Back to top
View user's profile Send private message Visit poster's website
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Thu Jun 26, 2014 9:46 pm    Post subject: Reply with quote
Yes, that is the relevant scenario, it seems. 34SP support has informed me today that my sessions are now being written to file (/tmp)--end of.

I've confirmed that my sessions have, since 24th June, been written to that directory (using your invaluable passthru line). No more errors. Problem circumnavigated.

Naturally I'm now impatient to dream up another futile project in preparation for the trashing routine...
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Fri Jun 27, 2014 9:08 am    Post subject: Reply with quote
@Phil
Both your link:
http://www.simplemachines.org/community/index.php?topic=486606.0
and one provided to me in a message from 'support':
http://robert.penz.name/663/session-verification-fails-after-update-from-php-5-3-to-5-4-with-suhosin/
led me to the following discussion:
https://github.com/stefanesser/suhosin/pull/26
which offered this fix:

Fix saving sessions in PHP 5.4 with user session handlers (fix #12)

I assume this is something that could be implemented by an individual with LAMP or something similar installed on their own box, or by a hosting company providing PHP 5.4 with the Suhosin patch applied.

Neither option is, it seems, relevant to my situation.

My solution: I have now copied all my files into another directory, changed the necessary references (links, includes/requires etc.) and am using my session handling class if & when there are no errors, and switching to the support version of my handling class when my own is trashed by Suhosin.

I'll continue posting updates here until a fix is implemented, Suhosin is updated, PHP version changes or I finally see the funny side...
Back to top
View user's profile Send private message
lauradoom
34SP Newbie
34SP Newbie


Joined: 17 Nov 2008
Posts: 30
Location: online

PostPosted: Fri Jun 27, 2014 9:12 am    Post subject: Reply with quote
Latest response from support:

In general, saving the sessions in the database isn't great. It is not really designed for that purpose and MySQL serves as a very poor tool for session storage, locking being a key issue - not to mention no built-in support for purging. There's also the fact that this is a shared server and adding this kind of load to the database if the site gets busy will lead to more troubles. Please do try to store them on the file system and let us know there's any further session troubles.
Back to top
View user's profile Send private message
Post new topic   Reply to topic    34SP.com Forum Index // Scripting Support All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Powered by phpBB © 2001, 2002 phpBB Group