I wanted to switch my server from the old mpm-prefork configuration to mpm-event, which seems to have worked successfully. However, Nextcloud isn’t a big fan. I can successfully read a php file with phpinfo() in Nextcloud’s webroot, but I get this error currently:
This is on FreeBSD 11.1-STABLE, and I followed these instructions here, and also what is said on the Nextcloud documentation regarding this here
I compiled Apache and PHP71 from ports and made sure to grab all the necessary PHP extensions listed in the documentation
Currently, I get 503 errors. However, if I drop my own script in there (like a php script that just echos hello), I can get the script to work. But any of the Nextcloud files will result in a 503 WSOD
I’m dumb. Caching during all of this I haven’t installed my caching module However, even with APCu reinstalled, I still get 503 soooo that’ll take some more work. In the meantime, this works again!
Hmmmm well, not sure what piece of the puzzle caused my issues, but CalDAV completely stopped working after switching to an Apache + PHP-FPM + HTTP2 server in general, reverted back to original everything for now
Everything seems fine, phpinfo() shows Server API FPM/FastCGI and Nextcloud is running.
Some guides also suggest to add
<Proxy "fcgi://localhost/">
</Proxy>
But it seems not needed and I cannot see any difference after adding it, thus left it out.
My question is now that as Apache still spawns child processes, even that php-fpm definitely is used.
I was thinking, that as just PHP files are handled by php-fpm, that static html files are still handled by Apache and it’s child processes, thus this is expected?
On the other hand, Nginx and Lighttpd do not need own child processes, thus html files seem to be handled by php-fpm as well or by their webserver master process?
The amount of Apache child processes btw. seem to be configurable via /etc/apache2/mods-available/mpm_event.conf.
Indeed it looks like Nginx (or Lighttpd), which natively is intended to be used with fcgi/php-fpm seem to be the more consistent solution then. The use of .htaccess (and that Nextcloud uses it actively) seem to be the only left argument for Apache…
Do you have any other suggestion about what should be changed about Apache2 (not PHP/FPM) settings/setup, besides the SetHandler above?
So far at least the switch is easy, compared to other solutions with libapache2-mod-fcgid and more complex looking implementation.
@stratacast
Sorry for hijacking your thread, I just thought to collect information in one thread has advantages. Did you actually find a solution, or are you still at mod-php?
I don’t know much about the difference between the SetHandler and ProxyPassMatch implementations, besides that SetHandler seems to be the most current solution and provides web socket support. I suggest you try it out, as shown above.
Please do hijack, I switched to nginx in the end. Much better Less mess hassling with having to compile apache24 for different worker processes and such
And the apache2.conf addition: SetHandler "proxy:unix:/var/run/php/php7.2-fpm.sock|fcgi://localhost/"
But first verify the PHP version in use, since the repo move from 7.0 to 7.2 was done not too long ago: php -v
Okay, but your enabled Apache modules already look fine. If the apache.conf points to the correct php-fpm socket, and as well according to the error message, it could be due to missing PHP modules or at wrong version, e.g.:
You use PHP7.2, but the php-apcu module is still at PHP7.0 (or 7.1 max). This was the case for a short time of repo transition 7.0 -> 7.1 -> 7.2, if I remember right. The same could be the case for php-redis + php-igbinary. If then Nextcloud, according to config.php try to access APCu, I guess the above errors can be thrown.
Check php -m to list all the enabled PHP modules and verify that whatever is needed or explicitly configured in config.php is in the list.
There is no .htaccess equivalent for Nginx, if this was the question. .user.ini can be used to set certain PHP settings and all webserver settings need to be placed in the Nginx config, e.g. inside the ^/nextcloud location directive to apply directory-wise.