|
mpurse
|
October 4, 2019 at 3:35 am
We’ve noticed recently the we’re often seeing the empty event queue error when visitors attempt to book events.
We’ve disabled all caching on the site (and don’t have any object caching), but the issue persists.
Looking through the WordPress debug log, we have noticed similar PHP warnings to the following:
session_start(): open(/var/lib/php/session/sess_vcgrffb9ejlus8lnj01k3nu9l6, O_RDWR) failed: No such file or directory (2) in /public_html/wp-content/plugins/event-espresso-core-reg/core/services/session/SessionStartHandler.php on line 65
Checking phpinfo() the session save path is /tmp, and I can’t see anything in the code of any active plugins (or themes) on the site that would cause the session save path value to be overwritten.
Do you have any suggestions as to what might be causing SessionStartHandler.php to attempt to save the session to the incorrect path?
|
|
Tony
|
October 4, 2019 at 3:49 am
Hi there,
SessionStartHandler.php is not actually attempting to read/save the session from/to any path. All it is doing there is calling session_start() and session_start() is attempting to save the session to that path.
EE doesn’t set the session path at all and doing so would not work well with distributed systems so its unlikely that any theme/plugin should set that path.
Where are you running phpinfo?
If you go to Event Espresso -> Maintenance -> System information
Search for session.save_path there, what does it show?
The path your server is currently using the in the above is the default path used when session.save_path has not been set, or has been set to nothing ('')
|
|
mpurse
|
October 4, 2019 at 4:00 am
Thanks for getting back to me.
Event Espresso -> Maintenance -> System information is correctly reporting that session.save_path is set to /tmp (both global and local)
|
|
Tony
|
October 4, 2019 at 4:38 am
Event Espresso -> Maintenance -> System information is correctly reporting that session.save_path is set to /tmp (both global and local)
That’s phpinfo just output in a readable format.
So whatever is setting session.save_path apparently hasn’t run when start_session is called above.
Where/how are you setting session.save_path to /tmp?
|
|
mpurse
|
October 4, 2019 at 4:45 am
/tmp is the server’s default session.save_path.
We’ve also tried manually setting a session.save_path in user.ini (which is where we already have other modified PHP configurations set), and phpinfo() is correctly reporting that value when it is set.
|
|
Tony
|
October 4, 2019 at 5:13 am
/tmp is the server’s default session.save_path.
Ok, but that doesn’t really answer my question.
How is that set? Which file is your ‘default’ config?
Your definition of ‘default’ for the above and mine may well be different.
It may seem like an odd question but having a session.save_path value apparently being ignored on certain requests, isn’t normal either 🙂
We’ve also tried manually setting a session.save_path in user.ini (which is where we already have other modified PHP configurations set)
user.ini is per-directory, meaning you can have more than one running from more than one location, overriding various options as you travel up the tree.
Have you checked for other user.ini or php.ini files anywhere on the server?
Have you tried running session_start() outside of EE to confirm if it works then?
|
|
mpurse
|
October 4, 2019 at 6:18 am
The default php config file would be /usr/php70/etc/php.ini
Other than our user.ini (found in public_html), I can’t see any other php.ini or user.ini files in either the root of wp-content, any plugin folder, or the active themes folder).
I’ve not yet tried running session_start() from outside EE, but I’ll try that and see if it returns the same error
|
|
Tony
|
October 8, 2019 at 6:49 am
Just checking in to see if you checked if session_start() throws an error when ran outside of EE?
|
|
mpurse
|
October 8, 2019 at 11:11 am
Hi Tony,
I ended up calling session_save_path() to set the session path immediately prior to session_start();, and while this cleared up the notice in the debug log it didn’t resolve the event queue issue (which I had hoped was related to the session).
In the end, dropping down to PHP5.6 (from PHP7.0) appears to have resolved the event queue issue.
Thanks for your suggestions and your help 🙂
|
|
Tony
|
October 8, 2019 at 1:03 pm
Hmm yeah, that’s strange.
At a guess I’d say opcache was enabled within the PHP7.0 config, did you check that? (It will need to be disabled).
The problem with downgrading to 5.6 is its now EOL with no support so our recommendation is to upgrade to PHP7.3
7.2 is about to go into Security Fixes only and anything below is eol:
https://www.php.net/supported-versions.php
So whilst working on this you may be better switching to PHP7.3 and troubleshooting that so you don’t need to update shortly anyway.
You could create a development copy on a subdomain and if you host allows set that subdomain to load PHP7.3 to work on it there.
|
