Bug 1516470

See explanation on 
https://blog.remirepo.net/post/2017/11/17/Fedora-27-changes-in-http-and-php

Is it mythweb from rpmfusion ?

So https://bugzilla.rpmfusion.org/show_bug.cgi?id=4716

I admit ignorance. In my simple mind, what has changed between fc26 and fc27 is: fc26 apparently was compiled as "threadsafe" and fc27 php is not compiled the same way as in fc26. fc27 php packages not being compiled threadsafe breaks mythweb.

Where the httpd module config file (mythweb.conf in this case) came from seems to me to be of no relevance. Is the use of php_value no longer valid in fc27 (when using mod_mpm_event.so, the answer is yes)? Can a web developer no longer easily use php_value (or is this term old/depreciated technology) in fc27?

Perhaps if Fedora sees this as no problem, I will attempt to look at the source packages for php from fc26 and fc27 and see if I can compile fc27 php threadsafe.

Alternately I might be able to install fc26 php packages on fc27 and test the results. I will try this method first. I will report back if I get favorable results.

Thank you for examining this issue so promptly. I hope I might be able to discover that the method used to compile fc27 php is the issue here, not where the httpd module came from. Anyway, thanks again for your prompt response.

I took php-7.1.10-1.fc26.src.rpm and compiled it in the fc27 environment using rpmbuild. I installed the minimum amount of php* rpm packages created, reconfigured httpd to use mod_mpm_event.so, and stop/started httpd.

httpd -t -D DUMP_MODULES | grep event
seems to confirm: mpm_event_module (shared)

mythweb works with no complaint about php_value.

I have no idea what security/performance problems this introduces and will not operate as currently set up. 

It does hint to me that the compile between fc26 and fc27 changed (for whatever reason) to make fc27 php non-threadsafe. I guess my next step is to download the fc27 php source and examine that for compile switch differences. With my abilities, that will perhaps not be easy.

It was a nice experiment.

Thank you for your time.

@Ronald, have you even read my link, in previous comment ?

In short, rebuilding the F26 package you simply enable mod_php in ZTS mode, which is NOT supported, and may raise various segfault (a simpler way is described in above link, as available in F27 package, only disabled)

It looks like your are not using the rpmfusion package which seems to be properly packaged (see discussion on linked bug), but a manually installed version.

mythweb upstream configuration for apache is not correct as it uses php_value.

You simply have to remove this php_value, and use instead a .user.ini file in the application directory

Again, this is explained in my blog article.


To be clear: moving from prefork MPM + mod_php to event MPM + php-fpm is a choice for modernity, performance and security.

Experiencing the same issue on following setup

CentOS 7.4.1708 (Core)
Kernel 3.10.0-693.17.1.el7.x86_64
Apache & Varnish Cache & Nginx Reverse Proxy
Apache/2.4.29
nginx/1.12.2
PHP 7.1.4 (remi-safe repo)
suPHP version 0.7.2
MySQL version: 10.1.31-MariaDB
SEL disabled
Mod Security disabled

"/etc/opt/remi/php71/php-fpm.d/www.conf"
php_flag[display_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path]    = /var/opt/remi/php71/lib/php/session
php_value[soap.wsdl_cache_dir]  = /var/opt/remi/php71/lib/php/wsdlcache

For the sake of completeness

httpd -V | grep MPM
Server MPM:     event