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 06 2017 Permalink
Are you using nginx or apache? Quite likely the user it is running doesn't have permissions to write sessions in that path. Also make sure the session path is defined in the configuration.

Also Anahita 4.3 is using database for storing sessions by default. I'm not sure why your installation is trying to use the default session mechanism.
Scott Crawford
Scott Crawford
March 06 2017 Permalink
I'm running Apache, however I just set permissions to 777 for both /tmp and /log and still have the issue. Site settings look right - /tmp and /log are both correct, and the People app settings are Yes for allow registration and Public for default access. I'm running 4.3.3 now, all else seems to be working fine.
Rastin Mehr
Rastin Mehr
March 06 2017 Permalink
Can you check and see if the sessions table get populated? Sessions are supposed to be stored in that table rather than flat files on your server.
Scott Crawford
Scott Crawford
March 07 2017 Permalink
Sessions are being generated when I log in as Super Admin, showing me as that user type, and it appears there are 2 or 3 others listed as "guest". When I attempt to register the test user account one seems to change to reflect username "NULL" whereas the user names were blank beforehand.

Since a session is generated when I'm logging in as SA that would confirm the database connection is working, correct?
Scott Crawford
Scott Crawford
March 07 2017 Permalink
... just closed the browser window and there are now 6 sessions
Rastin Mehr
Rastin Mehr
March 07 2017 Permalink
yes, the sessions are being created in the database then. The guest sessions are created for the site visitors and they are deleted within 15 minutes.
Unkown Person liked this
Scott Crawford
Scott Crawford
March 07 2017 Permalink
So, DB connection seems to be good, and with /tmp and /log permissions set to 777 (for now), where else might I look?
Rastin Mehr
Rastin Mehr
March 07 2017 Permalink
No the Linux user which is assigned to php should have write access. This seems to be a common issue in php apps. If you google the error message you may find answers in stack overflow or similar websites.
Scott Crawford
Scott Crawford
March 07 2017 Permalink
OK let me try something... may take a few hours but I'll report back either way
Scott Crawford
Scott Crawford
March 08 2017 Permalink
Question on the /tmp folder... the admin settings should be pointing to /home/[user]/[domain]/anahita/www/tmp , correct? Or should /tmp be pointing somewhere else?

All folders under my Anahita project are being run from the same user within the same groups and privileges. Site settings / config are pointing to the /anahita/www/tmp folder.

I've since initiated a new user account to transfer the domain to be served from in hopes this will give a 'fresh start' and circumvent whatever is causing the error, which I'm still waiting to complete.
Rastin Mehr
Rastin Mehr
March 08 2017 Permalink
the www/tmp folder is fine and it needs to have write permissions for php to use it. That particular folder is used by Anahita to temporarily store files such as compressed css, etc.

PHP sessions however are stored somewhere else and they are protected by the system. Only someone who gains root access to the server can access them. You can find the sessions's path in your php.ini file. The variable is session.save_path

What linux distro are you using?
Scott Crawford
Scott Crawford
March 09 2017 Permalink
It's looking very likely something is going on in the database on this one... still working to pin it down. I re-installed from scratch the live site while pointing at a fresh (empty) database... e.g., I did not "migrate-up", I just installed to an empty DB. I installed all apps, confgs, etc, and no issues during installation and no issues creating a new user once everything was set up.

I then pointed the config file to the live project's DB and the error showed back up. So, the code base / server setup was the same, but when I pointed to the populated live DB the error persisted.

Starting to dig into the DB to see what's different now... I'll report back...
Rastin Mehr liked this
Rastin Mehr
Rastin Mehr
March 09 2017 Permalink
Something might have gone wrong in the migration. Start with comparing the database fields.
Scott Crawford
Scott Crawford
March 09 2017 Permalink
Just completed that. The migrated nodes table was missing the gender column, its timezone column was called 'timezone' instead of 'time_zone', and -- oddly -- it's migrator_versions showed anahita as 21 whereas the "fresh" installed showed anahita version as 19.

What about collation ? I've cleaned up most of the structural issues but notice a few collumns in nodes and edges having different collations... would that make any difference?
Rastin Mehr
Rastin Mehr
March 10 2017 Permalink
timezone isn't even being used at this point, but I don't like the migration version discrepancy. Although. The collations for title, alias, and description fields have changed to utf8mb4 to support emojis. What about the sessions tables and people_people tables?
Scott Crawford
Scott Crawford
March 10 2017 Permalink
I'm at a loss... I've confirmed three times that all tables have the same structure. What I'm doing is using the live site's file system, the live site's mysql account, and within that I have the "migrated" tables prefixed with "an_" and the fresh install tables prefixed with "fresh_". I have two Chrome tabs open with phpMyAdmin and I'm side-by-side comparing the "an_" tables to the "fresh_" tables.

I've changed all structure now, including collations, on the migrated data tables to be identical to the fresh tables.

To test the errors I log in on the front-end and change the Site Settings' DB table prefix from the front-end, log out, and then attempt to create the new user - doing so using each set of tables. The "an_" tables still kick out the error, while the "fresh_" tables do not.

People_people and sessions each show the same structure in my comparisons. In people_people the only difference I can tell is the legacy data has some time_zone data populated and the language fields are blank, whereas the only entry in the fresh table (first super admin) has these showing null. However, in the people_people structure these columns are similarly set to allow null / default NULL for both "an_" and "fresh_".

Sessions tables again appear structurally identical and each does capture my logged-in status similarly.
Scott Crawford
Scott Crawford
March 10 2017 Permalink
Ugh. I just ran a line-by-line comparison of the SQL code headers creating the "an_" and "fresh_" tables within the dump file. For all practical purposes they are line-for-line identical.
Rastin Mehr
Rastin Mehr
March 10 2017 Permalink
Where is your session path on Apache and does php have write access to it?
Scott Crawford
Scott Crawford
March 10 2017 Permalink
Running on a shared server, session path in phpinfo() shows /tmp off the root directory. I just logged in through the terminal via the user account the site is running on, navigated to /tmp, and successfully created and deleted a test file there - so it appears the user account does have write access.

Thinking through again this morning (while the coffee kicks in), what difference would there be in merely switching the table prefixes? Literally everything else seems to be identical, all that is change is the table prefix which I'm doing via the front-end Settings view.

Could something have caused one of the legacy tables to be locked?
Scott Crawford
Scott Crawford
March 10 2017 Permalink
I think I'm getting warmer... using all tables (nodes, edges, components, plugins, etc.) from the migrated data set except people_people, which is from the fresh install and only includes my super admin account, everything works without the registration error - i.e., I can create a new account without issue.

Now, when I delete the newly created user, set the people_people table's autoincrement value back to 2, and then import from CSV the legacy people_people data into this hybrid table, that pesky registration error returns but everything else seems to work perfectly - nodes, edges, all legacy content is otherwise as expected.

Very strange, all I'm doing is adding new records to a seemingly otherwise good table.

Powered by Anahita