I realize that Imagick has it's own command line executables, but why whenever I try to run an Imagick command written in PHP it breaks my script and exits without warning?
Take something simple:
<?php
$imagepath = realpath('1.gif');
var_dump('111');
$image = new Imagick($imagepath);
var_dump('222');
var_dump($image);
Running php -f imagick.php on my command line interface just simply outputs string(3) "111" and then immediately exits once it hits any Imagick function.
Imagick is properly installed on my machine, and if I do a php -m it shows Imagick as an installed module.
Is there anyway to get it working in command line scripts (aside from using exec())?
I was slightly worried that it wouldn't work on cron jobs, but I just did a quick test and it seems to be working within that (least on VPS).
Am trying from Windows x64 WAMP server PHP v7.1.16.
Note: To clarify, this is just a command line issue. Imagick is installed correctly, no issue with syntax, I've been using it for months in the browser with no issues.
Even command line attempts.. php -d display_errors imagick.php, same, dies upon impact of IM with no notice php -n -l -d display_errors -d display_startup_errors imagick.php brings back 'No Syntax Errors'. It's peculiar, nothing should simply kill the script (although it does try to load for a second before it essentially breaks out of the script no matter where it's at) without any notice.. then again since there's no issue running it in the browser over and over, so I don't think there is any errors (especially sampling my above one liner Imagick initalization).. it's just a CLI thing that I do not understand.
This was a local issue, apparently.
I recently reinstalled Windows and subsequently reinstalled Imagick and PHP.
Anyone else having similar issues I recommend reinstalling Imagick (it's a big pain to install -- recommend using these references for installing on a Windows 10 machine:
Installing Imagick for PHP 7 on Windows 10
Proper Way to CLI PHP within WAMP (WAMP64), while switching between Multiple PHP Versions on Windows 10
Also I've yet to try this personally, but by the looks of it, seems a better method for imagick integration with PHP: ImageMagickPHP (Imagick PHP Class that utilizes command line exec as opposed to the PHP version).
Related
Ok, after having bashed my head on this for hours I decided to ask for help. I have a Windows Server 2008 running Apache 2.4 and PHP 7.1. My application must run a PHP script on the server when the user clicks a button on the browser.
This is working fine on my desktop with Windows 10. However, on the server, exec() returns "null" and an exit code of 255.
I read all I could find on exec() issues and tried the following:
exec("C:\\PHP7\\php.exe -v", $output);
I got the proper response containing PHP's version information.
Then I decided to check the configuration files:
exec("C:\\PHP7\\php.exe --ini", $output);
All files were in place.
Then I decided to perform a syntax check on my script:
exec("C:\\PHP7\\php.exe -d display_errors=1 -l C:\\Apache24\\htdocs\\script.php", $output);
No errors were found.
Finally I decided to check the user account:
exec("whoami", $output);
Got "NT Authority\SYSTEM" as expected. To make sure that the script was able to run under the SYSTEM account I used SysInternals psexec:
psexec -s C:\PHP7\php.exe C:\Apache24\htdocs\script.php
Everything ran smoothly.
In other words, the script shows no problems when executed from the command line, either under a user account or the system account. I have also proven that PHP is being properly invoked by exec().
So, then I decided to check for "hidden" errors in my code adding the following two lines to the very beginning of the script:
error_reporting(E_ALL);
ini_set('display_errors', 1);
But, no joy. And I'm out of ideas.
Can any good soul help me on this?
Thanks a bunch,
Miguel.
Finally! The key to the answer was here: PHP exec() git fetch failing with return value 255.
I was unable to see any errors, even adding the "2>&1" pipe redirection to my commands. After reading that article, I learned that proc_open() is way better than exec(). Quoting from PHP's documentation:
proc_open() is similar to popen() but provides a much greater degree of control over the program execution
So, I replaced my exec() for a few lines of code (refer to the example in the manual) and found that the problem was being caused by the Zend Opcache, which was enabled for CLI. The quickier solution for me was to disable it in the command line:
php.exe -d opcache.enable_cli=0 myscript.php
Voilà! Problem solved!
I have updated windows today and now when I use the command line and type PHP nothing returns. tried various PHP commands, nothing, not even an error or response. blank.
I had the correct path in the environment variables. Tried to change to another PHP version and even tried removing the path from environment variables but still returns empty!
It doesn't even say that "PHP" is not recognized although I removed the environment variable!!
I have no clue how to solve this.
If you are not passing extra parameters when you call it from command line, that´s how it supposed to work.
Try running:
php --help (to see all options from command line)
Also, to make sure it is running try to do this:
php -v (to check version)
php -F filename.php
The last one should run your php file.
I had the same challenge.
Here's a solution:
Use a standard terminal window (instead of Powershell).
Try php -v again.
IF you get an error mentioning VCRUNTIME140.dll
THEN you need to install run-time components that are required to run C++ applications built using Visual Studio 2015 here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
So after a fresh install of laravel (v5.4) and using Mamp as my local server I just get (in chrome)
The localhost page isn’t working
localhost is currently unable to handle this request.
HTTP ERROR 500
I've tried countless things like changing permissions on storage or everything within the laravel directory.
Done composer update/install in the directory.
I'm running PHP v7.0.12 on my Mac (10.11.6). Cant think of anything else that would be causing this?
If I create another directory which a simple index.php with '' it loads absolutely fine so what is causing an issue with laravel?
Here's pics of my mamp setup
http://i.imgur.com/xT3mMZO.png
http://i.imgur.com/ddz9uij.png
Open up terminal and type:
tail -n 20 /Applications/MAMP/logs/php_error.log
This may give you some clue as to what is going on.
Hope this helps, happy coding :)
I just joined stackoverflow yesterday so I do not have enough reputation to comment. I write an answer here.
here is the short answer:
run :
PHP_VERSION=`ls /Applications/MAMP/bin/php/ | sort -n | tail -1`
echo "export PATH=/Applications/MAMP/bin/php/${PHP_VERSION}/bin:$PATH" >> .bash_profile
source ~/.bash_profile
check your php version by running php -v. close the terminal. Open another terminal and check php version again.if you see php 5 again then there are 2 possibilities:
First: you added the /path/to/php7 after /path/to/php5 and php 5 is loaded first.
Second: system loads another bash file first which your php 5 path is mentioned in it. I know that this sounds confusing having several bash file but it is. Please search for other files like bashrc or similars.
This is the long answer for anyone else:
first of all, if you are on mac, I highly suggest you to use valet to get rid of all these things.
But regarding the problem:
As you already noted that it is not a laravel issue. the php version that your machine uses is under the min required version by laravel. You have 2 versions of php at the moment. MacOs is shipped with php installed on that. I think it is the same php 5.5.36 that is making problem for you. Since Laravel 5.4, you need to use PHP >= 5.6.4.
Although you have installed parallel php 7 on your machine, you need also to check which php your machine is reading from by running which php. after that remember to add your path to php 7 installed to bash_profile or other bash files on your mac(you can have 4 or 5 bash files).
Considering you have only one bash file named as bash_profile and you are going to export the path to your php 7 to bash profile, If you run following command, that appends the path to the end of file
PHP_VERSION=`ls /Applications/MAMP/bin/php/ | sort -n | tail -1`
echo "export PATH=/Applications/MAMP/bin/php/${PHP_VERSION}/bin:$PATH" >> .bash_profile
remember to use source ~/.bash_profile in order to make changes effected.
Alternatively you can open the bash_profile file in your text editor by running:
open -a /Applications/TextEdit.app ~/.bash_profile
and add the path manually before the /path/to/php5 path.
finally you must check your php version by running php -v.
close the terminal. Open another terminal and check php version again. If you see php 7 then you are all fine. But if you see php 5 again then there are 2 possibilities:
First: you added the /path/to/php7 after /path/to/php5 and php 5 is loaded first.
Second: system loads another bash file first which your php 5 path is mentioned in it. I know that this sounds confusing having several bash file but it is. Please search for other files like bashrc or similars.
I built a pdf generator script for one of my clients and everything works properly. He then decided that he wanted me to create a thumbnail image from the PDF to display on another page, so I came across PHMagick and that seemed to do the trick.
The following code worked on my building server (iPage -- I think it's debian?), but now that I've moved it to his VPS, it is no longer working. FPDF has no trouble generating the pdf, so it is not a permissions issue.
Code:
require("phmagick/phmagick.php");
$pdf->Output("pdf.pdf");
$p = new phmagick('','pdf.png');
$p->debug = true;
$p->resize(800);
$p->acquireFrame("pdf.pdf");
This code returns the following error:
Error executing "convert "pdf.pdf"[0] "pdf.png"" return code: 127 command output :"sh: convert: command not found"
I have not changed any of the code since I moved it from the original server, and I just copied the entire site over, so why is PHMagick not working now? How do I get it to recognize convert.php in the plugins folder?
Just a note: I am only using PHMagick, not the whole of ImageMagick.
PHMagic appears to be using the command line convert command in background.
Most likely that command is simply not installed on the server.
PHMagic use the command line convert,composite etc... commands in background.
These commands are only available if ImageMagick is installed in your server.
In your previous server ImageMagick must have been installed.
Ipage sometimes do not pre install ImageMagick on their VPS servers. And you might not be able to install it your self ( through terminal login using ... yum install ImageMagick ) coz you will be prompt for root password.
To make sure the ImageMagick binaries are installed in ur server, in ur case the convert command,
type this command in the ssh terminal...
whereis convert
If the path to the convert command is not shown, it means you need to install ImageMagick.
You will have to open a support ticket and ask them to install it for you
As arkascha said, you'll need to install imagemagick. Try yum install imagemagick since you're running CentOS.
EDIT: May be a different capitalization: ImageMagick
When I call /usr/local/bin/pdftk from PHP in Apache (via shell_exec(), exec(), system(), etc.), it returns the SYNOPSIS message as expected.
When I call /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten via shell_exec(), nothing returns.
When I copy and paste the exact same string to the same path in the shell (as the apache user), the output.pdf file is generated as expected.
Moving the pdftk command into a PHP shell script (shebang is #!/usr/bin/php) and executing it with php script.php works perfectly.
Calling that shell script (with its stderr redirected to stdout) from PHP in Apache (via shell_exec(script.php);) results in this line:
sh: line 1: 32547 Segmentation fault /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten 2>&1
Whenever I run the script from the command line (via PHP or directly), it works fine. Whenever I run the script through PHP via Apache, it either fails without any notification or gives the SegFault listed above.
It's PHP 4.3.9 on RHEL4. Please don't shoot me. I've set memory to 512M with ini_set() and made sure that the apache user had read/write to all paths (with fopen()) and by logging in as apache ...
Just went and checked /var/log/messages to find this:
Oct 4 21:17:58 discovery kernel: audit(1286241478.692:1764638):
avc: denied { read } for pid=32627 comm="pdftk" name="zero"
dev=tmpfs ino=2161 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:zero_device_t tclass=chr_file
NOTE: Disabling SELinux "fixed" the problem. Has this moved into a ServerFault question? Can anybody give me the 30 second SELinux access controls primer here?
php-cli & php-cgi (or the module, depends on what your server uses) are different binaries. They don't even have to share the same version to live happily side by side on your server. They also may not share the same configuration. Increasing memory usually does nothing to help Segfaults. Points to check:
Are they the same version?
Do they have the same settings (consult the *.ini locations loaded in the phpinfo(); output, and possibly the whole output itself), if not: try what happens if you alter the one for your webserver to the one for the cli as far as possible.
Segfaults occur more in extensions then in the core afaik, and sometimes seemingly unrelated. Try to disable unneeded extensions one by one to see if the problem goes away.
Still no success? You may want to run apache with gdb, but I have no experience with that, it might tell you something though.
No luck? Recompile either the module of cgi your webserver uses.
It's PHP 4.3.9 on RHEL4. Please don't shoot me.
I feel more sad for you then anger, we're beyond the 5.3 mark, come over, it's a lot more happy here.