PHP is not recompiling properly.
I have PHP 7.2 installed on Nginx using php-fpm on Centos 7. I am recompiling php with more options using ./configure, make clean, make, make test and make install.
Everything works well and no errors are thrown, except the updated php
compile is not being reflected on the phpinfo(); table. If you see the
"Build Date" it is not changing. The "Configure Command" is also not updating after recompiling.
Why could php not be recompiling and the "Build Date" not updating, and the "Configure Command" also not reflecting my changes?
I have restarted nginx, restarted php-fpm, and still no change. I can edit the php.ini file without problems as well and they do update, but the php itself is not updating after I recompile and add more options (--with-openssl). I even restarted the server. PHP files are served fine.
Can anybody help?
I just figured it out after about half a day.
The reason the new php recompile was not being recognized was because I needed to manually copy the new updated php-fpm program to the /usr/local/bin directory, like this:
cp sapi/fpm/php-fpm /usr/local/bin
And that fixed it. So basically php WAS being recompiled correctly, but that was not seen by the system because php-fpm was not manually copied to the directory nginx uses to pull php-fpm from. The file must be overwritten while php-fpm is turned off.
Bonus Tip
This is my command to reload php, php-fpm and nginx after recompiling:
# gracefully stop the php-fpm process
pkill -15 php-fpm
# copy the new recompiled php-fpm to the executable directory
cp -f sapi/fpm/php-fpm /usr/local/bin
# start php-fpm
/usr/local/bin/php-fpm
# signal nginx to reload
nginx -s reload
All in one line:
pkill -15 php-fpm && cp -f sapi/fpm/php-fpm /usr/local/bin && /usr/local/bin/php-fpm && nginx -s reload
Related
I'm testing file upload between client and server.
But file upload not working because below error.
Unable to move '/tmp/phpxQHW5q' to '/var/www/html/mri_image/test.jpg' in /var/www/html/server_form.php on line 49, referer: http://192.168.1.12/client_form.php
I have searched this problem at stackoverflow.
Most solution is permision problem.
So, tmp and mri_image folder own by apache and changed mod 755.
Then, not working i want to your help
For reference, my os is CentOS 7, php version is 7.3
I had an issue recently with Apache and PHP trying to write to /tmp, but stating that the script failed with an error "No such file or directory"
Centos 7 uses systemd, which has an awesome feature (PrivateTmp) that breaks Apache/PHP access to /tmp folders (particularly in cases where the files need to be shared to other processes/seen by others. This feature works by creating a sort of "virtual" /tmp directory for each process, so a file seen by Apache wouldn't be seen by PHP, etc.
First, copy the httpd.service and php-fpm.service files from /usr/lib/systemd/system/ to /etc/systemd/system using the commands below.
cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/. && cp /usr/lib/systemd/system/php-fpm.service /etc/systemd/system/.
After copying those into place, edit each copy of the files in the new location and change the line with PrivateTmp=true to PrivateTmp=false using vi, or your preferred text editor.
vi /etc/systemd/system/httpd.service
vi /etc/systemd/system/php-fpm.service
After those changes, you need to restart systemd, as well as php-fpm and apache.
Restart systemd:
sudo systemctl daemon-reload
Restart apache:
sudo systemctl restart httpd
Restart php-fpm:
sudo systemctl restart php-fpm
So I ran into something I'm just hoping I can get some understanding on. There is a clean Centos machine with a clean install of PHP. It had the mongoDB driver installed as well. When accessing the web app through the browser, it kept complaining the mongo client didn't exist. All of the installation procedures were followed, php.ini contained extension=mongo.so, and httpd restarted. PHP info() did not contain the Mongo conf. What ended up working was adding a mongo.ini file to the /etc/php.d directory with the extension=mongo.so written to it.
I'm getting a sneaky suspicion php.ini wasn't being loaded correctly, but I don't understand why. The reason I'm thinking this is, for one, it worked after adding mongo.ini. Second, there are mismatched PHP info() outputs from the CLI and browser gui.
and from the GUI
Both of these were snapped seconds apart. No configuration changes or restarts were made. For some reason the CLI output says the loaded configuration file was /etc/php.ini which was expected. The browser GUI however shows (none). What is going on here? Is this why the extension=mongo.so was never loading from the php.ini file?
versions
Apache/2.4.6
PHP/5.4.16
CentOS Linux release 7.3.1611
[someUser#someServer etc]# find / -name php.ini
/etc/php.ini
Is SO even the proper place for this? or should I move to a different forum?
update
After reading Grigory Ilizirov's comments, and doing some research, I think the question is answered if he wants to post it. Looks like the php configs for apache wasn't being loaded. I had just assumed the /etc/php.ini file was all that was needed to be edited. Now I just need to figure out how the heck I'm going to do that.
update 2
Reverted back to a clean install and did everything again. This time around, same results from the CLI and web GUI as before, but now mongo wouldn't load at all despite being added in /etc/php.d/mongo.ini. suspect SELinux is interferring with apache. mongo.ini is no longer showing in the additional .ini file sections. Disabling SELinux and rebooting allows it to load to apache.
FINAL
This is indeed an SELinux issue. Now then, does this belong on SO for future users?
You need to make sure your PHP have installed MongoDB extension.try use PHP -m see if you have MongoDB installed.
Then Download source code from https://github.com/mongodb/mongo-php-driver-legacy.
follow these steps to install the extension:
tar zxvf mongo-x.x.x.tgz -C ../
cd mongo-x.x.x/
phpize
./configure --with-php-config=/usr/local/php/bin/php-config
make clean
make
make install
extension=mongo.so //add this line to php.ini
after install try run PHP -m again, see if extension installed success.
for more info, you should read PHP doc.http://php.net/manual/en/mongo.installation.php#mongo.installation.fedora
It was indeed SELinux interfering with Apache's access to the PHP configuration file. Adding the security context fixed it.
semanage fcontext -at httpd_sys_content_t '/etc/php.ini'
semanage fcontext -at httpd_sys_content_t '/etc/php.d/(/.*)?'
restorecon -Rv /etc/
systemctl restart httpd
I've downloaded php5.6 from here https://www.mamp.info/en/downloads/ and added it to php folder. After that I can't run Apache server. I removed that folder, but Apache still doesn't work. Files in /Local/logs/ are empty.
Mac OS Mavericks.
Same problem here. A (temporary) solution is to start apache from the terminal:
sudo /Applications/MAMP/Library/bin/apachectl start
MAMP detects it as its status light becomes green! But I cannot explain why MAMP doesn't command apache anymore, with nothing logged.
Tried to modify file /bin/startApache.sh, adding a sudo before start command, without success.
So I'm running MAMP on Mountain Lion and I've installed gmagick and imagick using pecl, both are relase candidates (mainly because gmagick doesn't have a stable release and imagick 3.0.0 doesn't install, it gives a make error). The modules appear when I run php -i in the terminal but not in phpinfo(), I have checked the php.ini it is the same for both so that is not the issue.However I have installed bitset(which is a stable release) and it appears in phpinfo() and php -i. So my question is does PHP have any configuration option that does not load extensions if they are not stable? Btw, I did restart my server after the changes to the ini file.
You will probably now have two php installations on your machine. Mountain Lion ships with a preinstalled php version. Trylocate php.ini in Terminal to find out how many php.inis are installed.
In your phpinfo() page there is also noted which php.ini is in use. You might want to open the exact php.ini which is used for your phpinfo() and make sure the extentions are loaded.
There should be two lines like
extension=/path/to/gemagicext/gmagic.so
extension=/path/to/imagick/imagick.so
I faced a similar problem with php-fpm and nginx server. The problem was due to the fact that the updated php configuration was not reflected in the current active php-fpm worker processes. I have to manually kill the fpm process and restart it again to have the updated extensions info.
Steps that worked for me:
1) Look for active php-fpm process
ps ax | grep "fpm"
mostly this will list more than one process
2) kill process manually
kill -9 [pid_got_from_previous_command]
3) restart php-fpm process
sudo service php5-fpm start
Note: Trying something like sudo service php-fpm reload or sudo service php-fpm restart didn't work since the old child processes retained the old configuration. Killing the active processes and restarting php fpm what updated the phpinfo for me.
I had the same problem CentOS 6.6 x64, php 5.5.27 and I followed the steps from
http://php.net/manual/en/imagick.installation.php
First of all download a tar image of the ImageMagick install from here:
sourceforge.net/projects/imagemagick/files/
Unpack it and then from terminal issue the following commands:
1. "cd ImageMagick-6.9.1-10" - go where you placed the folder
2. ./configure
3. make
4. make install
5. make check
6. install imagick extension from pecl.php.net/package/imagick/download 3.1.2
7. cd imagick-3.1.2
8. phpize
9. ./configure --with-imagick=/opt/local
10. make
11. make install
12. Copy imagick.so in your PHP extensions folder and add extension=imagick.so in php.ini
Restart apache: service httpd restart
I am sure this problem is related to your extension and PHP server compatibility. I encountered such problems when I created my own extensions. Your extension should compatible with your PHP server in three main attributes:
1- The Zend API number which your PHP server is configured with ( in phpinfo() you can find this number), this number should be the same with your extension header file at build time.
2- The compiler version on your PHP server and your extension must be the same.
3- Thread safety in your PHP server is important. If you use thread-safe server then your extension must be built with php thread-safe library and if you use non-thread safe server you should build your extension with PHP-nts library.
I'm trying to install zend debugger in my Ubuntu 9.04 machine, I've done it in win. but not in linux, I hope you could help me, this is what I've done:
1)Copied the file ZendDebugger.so to /etc/php5/apache2 (didn't choose this folder for anything in special).
2)Added this lines to php.ini:
zend_extension="/etc/php5/apache2/ZendDebugger.so" zend_debugger.allow_hosts=127.0.0.1,127.0.1.1,localhost,*
zend_debugger.expose_remotely=always
I've also tried without quotes(zend_extension=/etc/php5/apache2/ZendDebugger.so)
3)Copied file dummy.php to /var/www
And then restarted Apache but I didn't see the information about Zend Debugger in the phpinfo(), the only related thing I found there was report_zend_debug On.
Thanks in advance
I found much more easy to install Xdebug in my Ubuntu machine.
sudo mv /etc/php5/apache2/ZendDebugger.so /usr/lib/php5/20060613/ZendDebugger.so
This is where your memcache.so, apc.so, etc. are located. Unless you modified your php extensions directory that is where new exts should go.
In php.ini:
zend_extension=/usr/lib/php5/20060613/ZendDebugger.so
cd to that directory and chmod a-x ZendDebugger.so to remove executable bits from the .so.
sudo /etc/init.d/apache2 stop
In another terminal window, tail -f /var/log/error.log and clear console so it is easy to see new log entries coming in (cmd-k on macos).
Then:
sudo /etc/init.d/apache2 start
If there are no errors in error.log, check phpinfo() and see if the debugger section shows up.
You might get errors in the configuration of other php extensions that occur further up in php.ini (e.g., xcache or eaccellerator) that will make loading stuff further down in php.ini problematic.
This is a baseline setup and should work if there are no other problems.
You can also try to install Zend Server Community Edition
You'll get Zend Debugger enabled by default, along with some other nice features. There is a link to the deb repository available through the download page.
I followed the same steps that you did with the same result. In the end the problem was that I was trying to load a 32bit binary with apache running in 64bit mode base (as described in this post) I was able to get it running immediately by doing the following.
stopping apache
executing sudo arch -i386 /usr/sbin/httpd
restarting apache.
After replacing the 32bit binary with the 64bit binary everything worked as expected with no special apache handling. There was also some facepalming involved, but it did not affect the overall outcome.