From Bugzilla Helper: User-Agent: Mozilla/4.0 Description of problem: I downloaded and installed the fix for the "apache+php" remote exploit, 4.0.6- 12, and afterwards apache will not start. strace -o st -f /etc/init.d/httpd start reveals that apache coredumps: 21982 munmap(0x42b8e000, 153472) = 0 21982 --- SIGSEGV (Segmentation fault) --- 21980 --- SIGCHLD (Child exited) --- 21980 _exit(0) = ? however, by starting /usr/sbin/httpd, apache starts fine. This is because the parameters to load modules are not set. (but then, php/ssl etc modules are not loaded!) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. rpm -Uvh php{,-imap,-ldap,-mysql}-4.0.6-12.rpm expat-1.95.1-7.rpm 2. /etc/init.d/httpd restart --- httpd claims to have started OK, but has infact not. 3. Downgrade to the older PHP and everything works OK Actual Results: apache coredumped Expected Results: apache should be running Additional info: The system is a RH7.1 with apache/ldap/ssl upgraded to the 7.2 versions, so a library inconsistency could be the problem. However, then the RPM dependencies should be set to indicate which versions were needed.
Do you have the glibc update for RHL 7.1 or RHL 7.2 installed? There was a dynamic linker bug which was excercised by php which might not have been fixed yet in the stock glibc for RHL 7.1.
Installing glibc-2.2.4-19.3.i386.rpm glibc-common-2.2.4-19.3.i386.rpm glibc-devel-2.2.4-19.3.i386.rpm .. solved my problem. I suggest that the PHP rpm's have a versioned depends on this particular glibc version ... so if php is installed, atleast 2.2.4-19.3 of glibc would be required. Not everyone wants to touch production systems by always installing the latest updates of every package... but to close the PHP bug, php had to be installed. and hence, it would be nice to be "forced" to install the (implicitly) required glibc version. Thanks anyway for quick resolution of the matter. /S