Issues with Xenforo and php-fpm73 causing blank screens

Black Tiger

Well-known member
I keep getting issues with Xenforo and php-fpm73. Ran into this already several times. But it does not happen at specific moments as far as I can see.
It crashes php-fpm73 partly.

I first thought it was a php-fpm or config issue, but after thourough investigation I discovered it started happening after Xenforo installation. And always occurs when I'm using the admin panel.

What is happening is the following.
I do something (mostly admin cp, for example searching something or changing an option) then I get an oeps and furthermore I can't do anything, every php website on the server is presented with a blank screen.
PHP-fpm is running, but I have to restart it to get things working again.

The only consistend things are the following.
I do see several of these exit code 70 happening in the php-fpm73.log file.
[07-Feb-2021 01:57:33] WARNING: [pool myforum] child 24809 exited with code 70 after 13.240057 seconds from start
[07-Feb-2021 01:57:33] NOTICE: [pool myforum] child 24826 started
[07-Feb-2021 01:57:44] WARNING: [pool myforum] child 24826 exited with code 70 after 10.423605 seconds from start
[07-Feb-2021 01:57:44] NOTICE: [pool myforum] child 24830 started

But it's not a memory issue. We've got 64 GB RAM in that server and when this is happening, still almost half of the memory is free.
We got 100 max_childs and 1000 max_requests and we don't get anywhere near that.
Nothing in the apache error logs.

The only other consistent thing when this is happening is that this line occurse in my domain.log for my domain where Xenforo is running on.
84.xx.xx.xx - - [07/Feb/2021:01:58:41 +0100] "GET /service_worker.js HTTP/2.0" 304 47 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20
100101 Firefox/85.0"
However, I see loads of this line in the domain logfile, without it causing any issues.

Same issue happened during installation and once during import when starting Xenforo, which made me do all again using the CLI version.
I did never have this issue with other software before and php-fpm73.
We had IPB running, no issues, there is a phpBB forum running, no issues. Only happening when I'm walking around or doing something in the Xenforo Admincp.

Server info:
CPU Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
Server version: Apache/2.4.46 (Unix)
MariaDB 10.2.36
Cache: Opcache (no other cache enabled or present)
Tried with 256 and even with 512 MB memory_limit in the php.ini but does not make any difference.

These are also present:
GD (with JPEG support)

We do have this in the php.ini:
disable_functions = system,popen,shell_exec,exec,dl,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,show_source
but I was told this might only interfere with phpmail and image galerie, which are both not in use.

It happened several times now and we are looking for a solution, because other customers on the server start to complaint about the white screens.


Well-known member
do you get 200 OK http status code on the white pages? the config could be wrong.

Black Tiger

Well-known member
I don't get anything on the white pages, nothing is loading anymore, log entry's stop too, php-fpm73 is running as a zombie process it seems. According to the status it's running, but in fact it does nothing until restarted.
And I don't run Nginx, only Apache.
But thank you for thinking with me.


Well-known member
Do you have php error reporting enabled?

If I have a php error, it would show a blank page to me because I keep most publicly-viewable error reporting disabled. When this sort of thing happens I block all users at the firewall and enable error reporting so that only I can see what is going on.

Black Tiger

Well-known member
Normally our php errors will appear in the domains error log. We're using directadmin.
But it's not only my forums, if php-fpm goes dead/zombie like this, it causes white screens on every domain from every customer using php. It's a shared server.
It's very odd, only happening on this server.

I think we're going to convert back to mod_php with mod_ruid2 and see what happens then, since we can't get a finger behind this issue.