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:

[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
View Best Answer
zagrodzki replied on at Permalink Reply
Also present after 8.5.4 upgrade.
bleenders replied on at Permalink Reply
bleenders
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.
bleenders replied on at Permalink Reply
bleenders
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.
zagrodzki replied on at Permalink Reply
this matches also how the upgrade was done on our website - via the CLI, by replacing the entire concrete directory.
bleenders replied on at Permalink Reply
bleenders
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.
tasos replied on at Permalink Reply
The error is caused by session-less requests. To reproduce the error use a session-less http get request, something like :

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.
zagrodzki replied on at Permalink Reply
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.
zagrodzki replied on at Best Answer Permalink Reply
tasos replied on at Permalink Reply
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 !
DeWebmakers replied on at Permalink Reply
DeWebmakers
I can confirm this bug on php-fpm74!
Please apply the fixes on new versions.

concrete5 Environment Information

# concrete5 Version
Core Version - 8.5.3
Version Installed - 8.5.3
Database Version - 20200501000000

# Database Information
Version: 5.7.30-0ubuntu0.18.04.1
SQL Mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

# concrete5 Packages
SimpWeb (0.1.9)

# concrete5 Overrides
None

# concrete5 Cache Settings
Block Cache - On
Overrides Cache - Off
Full Page Caching - On - If blocks on the particular page allow it.
Full Page Cache Lifetime - Every 6 hours (default setting).

# Server Software
Apache/2.4.29 (Ubuntu)

# Server API
apache2handler

# PHP Version
7.2.24-0ubuntu0.18.04.6

# PHP Extensions
apache2handler, calendar, Core, ctype, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, Phar, posix, readline, Reflection, session, shmop, SimpleXML, sockets, sodium, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zlib

# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 512M
post_max_size - 512M
upload_max_filesize - 512M
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
opcache.max_accelerated_files - 10000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5

Browser User-Agent String

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36