session_start(): Failed to read session data: user (path: /var/lib/php/sessions) #17310
Comments
magento-engcom-team
added
the
Issue: Format is valid
|
Hi @AykutCevik. Thank you for your report.
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
where @AykutCevik do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?
|
engcom-backlog-nickolas
added
the
Issue: Clear Description
|
Hello @AykutCevik, thank you for your report. I'm not able to reproduce this issue on 2.2-develop branch. Could you please specify magento version you use? |
|
@AykutCevik Can you tell us which link you followed to install Redis? |
|
@engcom-backlog-nickolas I'm using Magento CE 2.2.5. |
|
Yes, the website you followed to install Redis. |
|
Agree with @AykutCevik we have this appearing in I was able to replicate using the view order > view order grid as @AykutCevik suggested, for a split second I saw the error on the Order view page, before being taken to the order grid. Here is the stack trace generated: From searching online, it appears to be either |
|
May this be related to |
|
@AykutCevik, thanks for feedback, and @josephmcdermott for details. I've tested on 2.2.5 with order view and order grid. Also I've been trying other different manipulation and still couldn't get described error on screen nor in logs. |
|
@AykutCevik I believe this is indeed due to the @engcom-backlog-nickolas, to consistently replicate the issue please try the following steps: Preconditions
Steps to reproduce
* if you aren't seeing this error, check in your PHP sessions directory. It should be empty (as Redis is the session back-end of course), however if there are session files building up in the directory, you are seeing a symptom of the same problem here, although it hides the error because PHP handles the session as a fallback. @AykutCevik try a This is all happening because of contention for accessing session data from single threaded Redis. The This same error will happen also on the front-end of Magento2. Try it by opening 10 or more tabs of different pages; clear the FPC (or just disable full page cache to emulate hitting un-cached pages); reload all the tabs at once as above and again some will fail. This is particularly bad when you have items in your cart as the local storage is not synched, resulting in the "I have no items in my cart, but there are items in my mini-cart" scenario I'm sure you've come across. I would suggest that "6" as a default for Would be great to get a view from Magento on this! Thanks |
|
Update on the above comment Having looked further in to this, I think potentially my above comment may not be completely accurate. The key being the code implementation of the function below:
This function implements the locking mechanism and appears to hold the lock per $sessionId. So this issue is not a problem globally across multiple sessions after all. I.e on a flash sale day, it would not be the case that the first 6 concurrent requests globally would get through and the rest bounce. Instead you would see all requests served but for each individual user's session only 6 concurrent requests allowed through. To test this, I have repeated the front-end mass concurrent reload steps from before (with Here 100 concurrent requests are served no problem with no failures despite sessions being started. Having discovered this I am happy that the 10% of PHP processes (php-fpm The likelihood is that this limit will only ever be exceeded by admin users trying to do too much at once, or abuse of the front-end. It would still be great to get a line from Magento here to confirm. Apologies if this is going back over old ground that may have been covered elsewhere. Thanks |
|
@AykutCevik, we are closing this issue due to inactivity. If you'd like to update it, please reopen the issue. |
|
A Magento core dev may have a look since we can't provide any updates. |
|
I can confirm this is currently happening on our site (Magento 2.2.5). We're getting non-responsive checkout process randomly happening. The max_concurrency value was still at the default value of 6. I'm increasing it to 30. The permission for /var/lib/php/sessions are set to drwx-wx-wt root:root, which explains why the FPM pool cannot read in it, but it obviously shouldn't be trying as redis should be acting as session backend.
|
ghost
self-assigned this
|
Hi @engcom-backlog-nazar. Thank you for working on this issue.
|
ghost
added
the
Issue: Confirmed
|
HI @AykutCevik Thank you for you report, the fix for this issue has already available in 2.2-develop and 2.3-develop branch, fixed by this pr -> #17608 |
ghost
added
Fixed in 2.2.x
|
@engcom-backlog-nazar I am still seeing this issue in 2.3.0. I am using it for sessions and cache, both on different ports. This is a major issue, as it causing payments to fail in dev environment - which makes it look like a coding issue with the plugin but I believe in fact it is due to Magento not being able to read session data. Is Magento falling back to /var/lib/php/sessions? Would that cause a different session and therefore no quote? Is there a permission issue? Is Magento 2 compatible with redis 5.0.x? report: redis-cli -v ls -la /var/lib/php/ There are session files in the folder. php-fpm7.2 -i | grep session max_concurrency is 6 in app/etc/env.php, max_children in php7.2-fpm is 15. |
m2-community-project
bot
added
Progress: ready for dev
and removed
Progress: PR in progress
labels
engcom-November
added
Area: Framework
Issue: Confirmed
|
❌ Cannot export the issue. This GitHub issue is already linked to Jira issue(s): https://jira.corp.magento.com/browse/AC-791 |
|
Just came here to see that the issue is not resolved for over 3 years. 😔 This happens for me sometimes on the frontend product page. Any help? |
|
I tried to increase (In my case I have these values) To solve the error, I set I hope it helps some of you. |
|
Having the same issue after adding several user roles (acl). Now the adminhtml is insane slow and sometimes this error occurs and a error page is shown. We're using 2.4.3-p1. |
|
Related to #3374 |
|
After reading through this thread multiple times and looking into the relevant Magento code, I think that the following is going on:
Considering all this, I ended up subclassing |
|
We also meet same problem, increase |
|
@engcom-November Could we have update status of this ticket |
|
FWIW, it still happened here in a 2.4.3 installation which was not even live yet, so there was not much concurrent traffic. But at least increasing max_concurrency seemed to help |
Sure, but this was just a workaround, was there any further investment on the others solutions |
|
Still reproducing this on a 2.4.3-p3 instance using the default session redis config with a Is there anyone from magento team working on this ? |
|
2.4.2 here, can't fix it. |
|
Happening in 2.4.6-p2 as well. |
and others
While viewing the orders page in the admin area and opening several orders I'm facing an error message.
Preconditions
3.1 see session config:
Steps to reproduce
Expected result
Actual result
Message in step 6 of reproduction appears, in the log I can find the following:
The path
/var/lib/php/sessionswas never set anywhere. I actually can't understand why Magento is trying to use the path when redis is configured. It may be related toSessionManager->registerSaveHandler()?The text was updated successfully, but these errors were encountered: