Topics

Tribe Support

Tribe Support's Topics

Scott Crawford

Scott Crawford

March 06 2017

libraries/default/sessions/sessions.php error when signing up new user

I've been consistently prevented from signing up a new user on my live site now, even after confirming everything was working properly in my dev environment.  The error being reported states:

"Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp) in /.../beerlovers.com/anahita/vendor/anahita/anahita/src/libraries/default/sessions/sessions.php on line 521".This is encountered immediately after signing up for an account at https://beerlovers.com/people/signup.

I have no template over-rides active.The /tmp folder exists, and has the permissions 755, and my dev environment resides on the same shared server as my live site.  PHP info's for each can be found at https://beerlovers.com/phpinfo.php and http://wscadvtech.com/phpinfo.php  - however, I had removed the dev anahita installation this morning.

Any ideas what might be the cause?

#sessions #migration #people

  • 29 Comments
  • Last Comment by Scott Crawford
Rastin Mehr
Rastin Mehr
March 10 2017 Permalink
Try adding 5 or 10 records from your data and test.
Scott Crawford
Scott Crawford
March 10 2017 Permalink
This was working up to a point. Ended up manually adding 50 names, tested and still ok ... then after 130 the error came back. I'm thinking something is going on with the indexing.
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
March 10 2017 Permalink
There maybe a funny data causing this issue. Look for inconsistent username or email formats. Also make sure that the person node alias is the same as the username.
Scott Crawford
Scott Crawford
March 10 2017 Permalink
Looks like I found the needle in the haystack, just need to figure out what's not connecting. By re-building the people_people table a few at a time I was able to single out one entry which if I do not include in the table it clears the error, and then the error comes back if I add this person back in.

Nothing looks suspicious in this person's people table data. Next step for me will be to check for links in nodes and edges... all other tables don't include anything relevant to this user.
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
March 11 2017 Permalink
So if you delete that person, everything works fine? Check out the fields in the nodes table related to this person too. I'd check the alias first.
Scott Crawford
Scott Crawford
March 11 2017 Permalink
This one is now solved. Ended up fully deleting the person (whom I know so no big deal). There were three DB entries to delete, one each in people, nodes, & edges, all seems to now work fine.

Something among those three was somehow locked. As Super Admin I was not able to delete, edit, or even un-follow the person from the front-end... each attempt was greeted by the original error.

Interesting how that lock prevented even new users from signing up, and more interesting how at first it appeared to be an issue with the file system, which it wasn't.

If I was working on a car, this would be the point I'd get out from underneath, drenched in oil except for the owl-eyes where my glasses had been... and probably bang my head on something trying to stand up :)
Rastin Mehr
Rastin Mehr
March 11 2017 Permalink
Don't let this go, I am curious to know what was wrong with the data, because it could happen again, because of Murphy's law.

For example try changing their username and alias and see if it still breaks. Or was it a broken edge which was causing the issue?

ps: you need a pair of steampunk goggles for this one
Scott Crawford
Scott Crawford
March 11 2017 Permalink
I might continue with the experimentation later this weekend; I'm a bit burned out for now. I was with the person when the signed up, it was several years ago, and I don't think they had any activity since.

Visually inspecting each of the three entries versus known-good equivalents nothing at all appeared out of place. I had copied the alias from the people table to the nodes entry and the error still persisted.

Globally I had removed an auto-follow group and deleted the plugin but it didn't seem to affect anyone else. In practice I hadn't been particularly disciplined in taking the project off-line for a while before running upgrades, etc., so my bet would be something was interrupted and one of the entries was locked up by the DB.

I did retain a backup copy of the corrupted data set so I can revisit.
Scott Crawford
Scott Crawford
March 11 2017 Permalink
I should add... now that I'm thinking back, when I performed the db:migrate:up procedure I was prompted by the system to re-run the migration. That had happened both when setting up the staging server and again when migrating the live data.

Quite possibly this lock was in a prior version. I did have some issues in 4.2.2 with new users registering and a string of 'dead' accounts that probably go back to 4.1.8 or 4.1.4 a year beforehand.

Powered by Anahita