Uncaught exception on session_write_close after upgrade to 8.5.3
Permalink 4 0 Browser Info Environment
Since an upgrade 8.5.2->8.5.3 I now see these in my Apache error log:
I also see a growing number of running Apache processes, with the growth coinciding exactly with the time of the upgrade, so I suspect it's related. My Selenium-based prober started timing out regularly about 25% of the time, which I also believe is related.
[Fri Jun 05 13:27:44.482530 2020] [php7:error] [pid 107994] [client 46.229.168.144:30100] PHP Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in [no active file]:0\nStack trace:\n#0 [internal function]: session_write_close()\n#1 {main}\n thrown in [no active file] on line 0
I also see a growing number of running Apache processes, with the growth coinciding exactly with the time of the upgrade, so I suspect it's related. My Selenium-based prober started timing out regularly about 25% of the time, which I also believe is related.
Status: New
Also present after 8.5.4 upgrade.
Yup, super annoying. Did not happen on 8.5.2. Upgraded the staging server yesterday to 8.5.4 and now it keeps crashing.
Every time I someone logs out, php-fpm completely stop responding on the next request.
Happens on my production and staging environment but locally it does not happen.
We're using nginx as reverse proxy on apache2 and php7.3-fpm.
Hopefully they can acknowledge the issue or point us to the direction what might be the cause.
Every time I someone logs out, php-fpm completely stop responding on the next request.
Happens on my production and staging environment but locally it does not happen.
We're using nginx as reverse proxy on apache2 and php7.3-fpm.
Hopefully they can acknowledge the issue or point us to the direction what might be the cause.
So this does not seem to happen on a clean install.
I suspect it has to do with the way we upgraded. We simply replaced the entire concrete folder. And then visit the website. This always worked for us in the past and locally it does not seem to cause any problems. But somehow this strategy wont work on our staging and production servers.
Would still like to know why it happened. No errors in any of our logs (Nginx, Apache, PHP-FPM). We set php-fpm logging to debug, but still nothing.
I suspect it has to do with the way we upgraded. We simply replaced the entire concrete folder. And then visit the website. This always worked for us in the past and locally it does not seem to cause any problems. But somehow this strategy wont work on our staging and production servers.
Would still like to know why it happened. No errors in any of our logs (Nginx, Apache, PHP-FPM). We set php-fpm logging to debug, but still nothing.
this matches also how the upgrade was done on our website - via the CLI, by replacing the entire concrete directory.
Ok, so that earlier statement about the clean install is not true.....
It happens on a clean install as well.
BUT, it happens ONLY when an Administrator logs out.
We have have multiple groups who can edit content. None of those groups experience this problem, just administrators. We use advanced permissions and workflows.
It happens on a clean install as well.
BUT, it happens ONLY when an Administrator logs out.
We have have multiple groups who can edit content. None of those groups experience this problem, just administrators. We use advanced permissions and workflows.
The error is caused by session-less requests. To reproduce the error use a session-less http get request, something like :
Doing a "diff -q" in the folders of versions 8.5.2 and 8.5.3, respectively between 8.5.3 and 8.5.4 and filtering the search with "session" we can see that there were some changes mage in the session handling. Maybe that could provide some more details to where to search for
Main side effect of this problem is that although the requests get a 200 response, the errors caused (mainly from legit bots) are enough to consume after some time a lot of memory and at the end choke the instance.
curl -X GET http://my.site.com
Doing a "diff -q" in the folders of versions 8.5.2 and 8.5.3, respectively between 8.5.3 and 8.5.4 and filtering the search with "session" we can see that there were some changes mage in the session handling. Maybe that could provide some more details to where to search for
Main side effect of this problem is that although the requests get a 200 response, the errors caused (mainly from legit bots) are enough to consume after some time a lot of memory and at the end choke the instance.
It's not clear to me whether these issues should be reported here and if anyone from the dev team is looking at them.
I found a similar issue reported on github:
https://github.com/concrete5/concrete5/issues/8824...
I'll try patching:
https://github.com/concrete5/concrete5/pull/8793/files...
https://github.com/concrete5/concrete5/pull/8901/files...
on my site and will report back if it solves the issue.
I found a similar issue reported on github:
https://github.com/concrete5/concrete5/issues/8824...
I'll try patching:
https://github.com/concrete5/concrete5/pull/8793/files...
https://github.com/concrete5/concrete5/pull/8901/files...
on my site and will report back if it solves the issue.
I can confirm that after patching both of:
https://github.com/concrete5/concrete5/commit/7c8ee15c889379c8c4885c...
https://github.com/concrete5/concrete5/commit/3af23cec322f730aa8904a...
I no longer see the issue.
https://github.com/concrete5/concrete5/commit/7c8ee15c889379c8c4885c...
https://github.com/concrete5/concrete5/commit/3af23cec322f730aa8904a...
I no longer see the issue.
At first, let me thank you for the time that you spent to reply / comment / point out the relevant github tickets & the corresponding patches.
Also for me, after applying the patches mentioned above, I can confirm that the error doesn't occur anymore.
Thanks again for your time !
Also for me, after applying the patches mentioned above, I can confirm that the error doesn't occur anymore.
Thanks again for your time !
I can confirm this bug on php-fpm74!
Please apply the fixes on new versions.
Please apply the fixes on new versions.
