I installed gearmand 1.1.5 on my server, and tried the examples provided with the installation after starting the server. They work pretty correctly (the echo example works, the reverse doesn't work as expected, but doesn't gives any error).
Then I installed the php wrapper using pecl. The version is the last stable (1.1.1). Obviously I added the extension to php.ini, and my php --info|grep gearman output is:
gearman
gearman support => enabled
libgearman version => 1.1.5
PWD => /root/gearman-1.1.1/examples
OLDPWD => /root/gearman-1.1.1
_SERVER["PWD"] => /root/gearman-1.1.1/examples
_SERVER["OLDPWD"] => /root/gearman-1.1.1
Then I tried the echo example in the pecl package, the worker starts correctly:
[~/gearman-1.1.1/examples]# php reverse_worker.php
Starting
Waiting for job...
the client, instead, gives me the following error:
[~/gearman-1.1.1/examples]# php reverse_client.php
Starting
Sending job
PHP Warning: GearmanClient::do(): send_packet(GEARMAN_COULD_NOT_CONNECT) Failed to send server-options packet -> libgearman/connection.cc:430 in /root/gearman-1.1.1/examples/reverse_client.php on line 26
PHP Stack trace:
PHP 1. {main}() /root/gearman-1.1.1/examples/reverse_client.php:0
PHP 2. GearmanClient->do() /root/gearman-1.1.1/examples/reverse_client.php:26
Warning: GearmanClient::do(): send_packet(GEARMAN_COULD_NOT_CONNECT) Failed to send server-options packet -> libgearman/connection.cc:430 in /root/gearman-1.1.1/examples/reverse_client.php on line 26
Call Stack:
0.0001 228408 1. {main}() /root/gearman-1.1.1/examples/reverse_client.php:0
0.0003 229552 2. GearmanClient->do() /root/gearman-1.1.1/examples/reverse_client.php:26
RET: 26
In the gearman daemon's log there is no sign of activity for this php tests, while it logged all previous examples I tried.
How can I fix this error? Thanks.
Your should always use addServer("127.0.0.1", 4730), not addServer(), despite what php documentation says.
In case if you have used something like this
$client->addServers('127.0.0.1', 4730);
or
$client->addServers();
and still it didnt work then use something like this
$client->addServers('127.0.0.1:4730');
PS - I have used localhost IP, this can be replaced with actual host IP.
Related
I downloaded the Google App Engine SDK for PHP but I am having problems with the installation of the PHP interpreter. I downloaded the source code from the link given but when I try to compile php the command make terminates with this error:
/bin/bash /home/david/Google/appengine-php-master/php-src/libtool --silent --preserve-dup-deps --mode=compile cc -Iext/jsonc/ -I/home/david/Google/appengine-php-master/php-src/ext/jsonc/ -DPHP_ATOM_INC -I/home/david/Google/appengine-php-master/php-src/include -I/home/david/Google/appengine-php-master/php-src/main -I/home/david/Google/appengine-php-master/php-src -I/home/david/Google/appengine-php-master/php-src/ext/date/lib -I/home/david/Google/appengine-php-master/php-src/ext/ereg/regex -I/libxml2 -I/home/david/Google/appengine-php-master/php-src/ext/sqlite3/libsqlite -I/home/david/Google/appengine-php-master/php-src/TSRM -I/home/david/Google/appengine-php-master/php-src/Zend -I/include -g -O2 -fvisibility=hidden -c /home/david/Google/appengine-php-master/php-src/ext/jsonc/json.c -o ext/jsonc/json.lo
In file included from ext/jsonc/json-c/json_inttypes.h:5:0,
from ext/jsonc/json-c/json_object.h:16,
from ext/jsonc/json-c/linkhash.h:16,
from ext/jsonc/json-c/json.h:22,
from /home/david/Google/appengine-php-master/php-src/ext/jsonc/json.c:34:
ext/jsonc/json-c/json_config.h:2:23: fatal error: ../config.h: No such file or directory
#include "../config.h"
^
compilation terminated.
Makefile:725: recipe for target 'ext/jsonc/json.lo' failed
make: *** [ext/jsonc/json.lo] Error 1
In fact there is no such config.h file in that directory so I can't understand how to solve this problem.
So I decided to search online the source code of PHP 5.4.19 and I compiled and installed it and everything worked. I followed all the other installation steps and everything worked.
Now if I start the server with the command
google_appengine/dev_appserver.py --php_executable_path=/usr/local/bin/php-cgi --php_gae_extension_path=/home/david/Google/appengine-php-extension-master/modules/gae_runtime_module.so my_app/
I get:
INFO 2016-03-25 15:04:19,209 sdk_update_checker.py:229] Checking for updates to the SDK.
INFO 2016-03-25 15:04:19,797 sdk_update_checker.py:257] The SDK is up to date.
INFO 2016-03-25 15:04:19,901 api_server.py:205] Starting API server at: http://localhost:51913
INFO 2016-03-25 15:04:19,907 dispatcher.py:197] Starting module "default" running at: http://localhost:8080
INFO 2016-03-25 15:04:19,909 admin_server.py:116] Starting admin server at: http://localhost:8000
ERROR 2016-03-25 15:04:21,270 php_runtime.py:348] The PHP runtime is not available
Traceback (most recent call last):
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 344, in new_instance
self._check_binaries(php_executable_path, gae_extension_path)
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 286, in _check_binaries
cls._check_gae_extension(php_executable_path, gae_extension_path, env)
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 241, in _check_gae_extension
ext_stdout))
_PHPEnvironmentError: "/usr/local/bin/php-cgi -m" returned an error [-6]
[libprotobuf FATAL google/protobuf/stubs/common.cc:61] This program requires version 3.0.0 of the Protocol Buffer runtime library, but the installed version is 2.6.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/home/david/Google/appengine-php-extension-master/remote_api.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program requires version 3.0.0 of the Protocol Buffer runtime library, but the installed version is 2.6.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/home/david/Google/appengine-php-extension-master/remote_api.pb.cc".)
Accordingly to the message the problem should be in the version of libprotobuf9 library. I have that library installed in my system (ubuntu 15.04) and in fact the version is 2.6.1. But by following the installation steps I installed protoc-3.0.0-beta-2-linux-x86_64 and protobuf-3.0.0-beta-2 in /usr. So, why does appengine use the wrong version of the library?
I thought about removing libprotobuf9 from my system but if I run sudo apt-get remove libprotobuf9 the list of packages that need to be removed is very big and contains things like
gnome-bluetooth gnome-calculator gnome-contacts
gnome-disk-utility gnome-font-viewer gnome-keyring gnome-mahjongg gnome-mines gnome-orca gnome-power-manager gnome-screensaver
gnome-screenshot gnome-session-bin gnome-session-canberra gnome-sudoku gnome-system-log gnome-system-monitor gnome-terminal
to me it doesn't seem a good idea to remove them. What's the solution to my problem?
First time asking a question here, please be gentle :-)
I'm writing a PHP command-line script on a Synology box to fetch files via ftps, and start out with this bit:
$ftp = ftp_ssl_connect("ftp.example.com");
When run from the command line, I get
Fatal error: Call to undefined function ftp_ssl_connect() in ...
phpinfo() tells me:
...
Registered PHP Streams => php, file, glob, data, http, ftp, https, ftps, zip, compress.zlib, compress.bzip2
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
...
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.1p-fips 9 Jul 2015
OpenSSL Header Version => OpenSSL 1.0.1p-fips 9 Jul 2015
and /etc/php/conf.d/extensions.ini contains extension = openssl.so (without an initial ;)
It seems to me that all the prerequisites for ftp_ssl_connect() are in place.
fwiw:
$ uname -a
Linux DiskStation01 2.6.32.12 #5644 Wed Oct 28 12:36:45 CST 2015 armv5tel GNU/Linux synology_88f6282_213
What would be the next place to look?
Type php -m to see the compiled in modules, as PHP does not ship the FTP extension by default if not on Windows. Calling phpinfo() should also show the compiler switches used, and if they include --enable-ftp.
The curious thing is I just tried this on an RS812 of mine, and it shows both the FTP and OpenSSL moodules as included, and it works fine:
nas-name> php -r "ftp_ssl_connect('test');"
PHP Warning: ftp_ssl_connect(): php_network_getaddresses: gethostbyname failed
in Command line code on line 1
This indicates the ftp_ssl_connect is working but not being able to parse the supplied host name. I have no idea why yours would be different unless you compiled PHP yourself.
As mentioned in Niels solution the ftp-Module is missing in the default installation. I needed the module in the CLI version of PHP, but it was unavailable on all four of my Synology Devices (DS 412+, DS 410, RS812+ and RS814+).
Enabling the module in the Web Station settings did not help, but there is a solution for the CLI version in a Synology Forum Entry:
make sure that the ftp extension is selected within php settings of Web Station.
then edit /etc/php/php.ini to include a line like this:- extension = /volume1/#appstore/PHP5.6/usr/local/lib/php56/modules/ftp.so
that's it. No restarting of Web Station or the NAS is required, as php loads itself from the commandline each time a call is made to php.
I am trying to run the Magento Cron job but get this error message. I checked phpinfo() which shows everything should be loaded and the get_loaded_extensions() shows => PDO [27] => pdo_mysql [28] => pdo_sqlite [29]
Any thoughts what I can do next to find the cause?
Thanks,
Chris
PHP Fatal error: Uncaught exception 'Zend_Db_Adapter_Exception' with
message 'The PDO extension is required for this adapter but the extension is
not loaded' in /home/k117235a/domains/greenman-chris.eu/private_html/lib/Zend/Db/Adapter/Pdo/Abstract.php:342
Stack trace:
#0 /home/k117235a/domains/greenman-chris.eu/private_html/lib/Zend/Db/Adapter/Abstract.php(248):
Zend_Db_Adapter_Pdo_Abstract->setFetchMode(2)
#1 /home/k117235a/domains/greenman-chris.eu/private_html/app/code/core/Mage/Core/Model/Resource.php(175):
Zend_Db_Adapter_Abstract->__construct(Array)
#2 /home/k117235a/domains/greenman-chris.eu/private_html/app/code/core/Mage/Core/Model/Resource.php(110):
Mage_Core_Model_Resource->_newConnection('pdo_mysql', Object(Mage_Core_Model_Config_Element))
#3 /home/k117235a/domains/greenman-chris.eu/private_html/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(320):
Mage_Core_Model_Resource->getConnection('core_write')
#4 /home/k117235a/domains/greenman-chris.eu/private_html/app/code/core/Mage/Core/Model/Resource/Db/Abstract
in /home/k117235a/domains/greenman-chris.eu/private_html/lib/Zend/Db/Adapter/Pdo/Abstract.php
on line 342
Probably you are checking the phpinfo() from the browser, but the extension might be loaded just for apache/nginx, and not for commandline, which is how I'm assuming the cronjob php file will run.
Check that the extension is enabled for CLI, typically in the following location:
/etc/php5/cli/conf.d/20-pdo_mysql.ini (the name might not be exactly the same)
It might be only on /etc/php5/apache2/ or /etc/php5/php-fpm/
You can just copy it from the other locations or create a new file with the following content:
extension=pdo_mysql.so
After that check that the extension is loaded by running from command-line:
php -i | grep pdo
If it's loaded you should see some output and the cronjob should now work.
I hope it helps.
Use "$ which php" to ensure you're using the PHP you think you are.
Look at the php.ini your command line PHP is using and see if any extensions are disabled
An alternate method is to have Apache run the cron jobs by using wget:
[specified time] wget -q http://magento.url.com/cron.php
Using this method also helps in cases where file permissions are an issue (specially when Magento's cache is involved).
Setup the GAE PHP sandbox on my Linux laptop (running Debian 'Wheezy' 32-bit, latest packages). Setup was done following the 'Installing the SDK' instructions, followed by an attempt at the 'Getting-Started > Hello World' application, following the instructions.
However, when I visit http://local.host.com:8080*, I get the following message, instead of 'Hello World!':
The path specified with the --php_executable_path flag () does not exist.
*Note: SO doesn't allow URL pointing to localhost, so replaced it with local.host.com! It is not a mistake.
On the console where I'd started the app_server, I see the following error-message:
ERROR 2014-04-29 03:34:36,219 php_runtime.py:223] The PHP runtime is not available
Traceback (most recent call last):
File "/home/icarus/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 219, in new_instance
self._check_environment(php_executable_path)
File "/home/icarus/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 148, in _check_environment
'flag (%s) does not exist.' % php_executable_path)
_PHPBinaryError: The path specified with the --php_executable_path flag () does not exist.
Note that I've installed the latest php-5.4.27 (instructions talk of php-5.4.25, but later go on to say in a NOTE that we can get the latest from PHP website), and built it on my machine, successfully as per instructions.
Is the php-5.4.25 hardcoded anywhere, s.t. it is not found, as on my machine I've got php-5.4.27 ? Here is what I see:
$ ls -l ~/php-5.4.27/installdir/bin/php-cgi
-rwxr-xr-x 1 icarus icarus 23195302 Apr 28 22:58 php-cgi
Python installed is 2.7.3, and the google_appengine SDK is latest stable i.e. 1.9.3.
Argh... I ignored to see the plethora of questions already on SO, on this (or nearly this) subject, most perhaps from newbies like me.
Based on this other SO question's answer, I started the SDK like this:
$ google_appengine/dev_appserver.py --php_executable_path=php-5.4.27/installdir/bin/php-cgi work/gae_apps/helloworld/
and finally 'Hello World!' worked as expected. Perhaps, this calls for bit of clarification / elaboration on the 'Getting Started' page ?
We have an intranet site that has multiple PHP scripts which start using curl_init(). The other day there was an update for ArchLinux which messed with some of the dependencies of cURL (glibc). This caused the curl module to not properly load in PHP, that is, extension_loaded('curl') fails.
I get this error from Apache /var/http/error_log:
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/modules/curl.so' - /lib/libc.so.6: version `GLIBC_2.16'
not found (required by /usr/lib/libcurl.so.4) in Unknown on line 0
The weird thing is we have another nearly identical script (on the same machine) that runs on PHP command line using curl_init() that runs via a cron job and PHP loads cURL properly during the execution of this script. That works perfectly fine.
cURL is configured to run in php.ini via extension=curl.so
If I check phpinfo(), I see '--with-curl=shared'. However it does not show the cURL info table. This tells me that the module isn't loading properly.
The curl.so file is in place at: /usr/lib/php/modules/curl.so
These cURL scripts also normally function properly, they are currently working great on another test machine.
This issue occurs on PHP 5.4.5
ldd /usr/lib/libcurl.so.4
linux-gate.so.1 (0xb7770000)
libssh2.so.1 => /lib/libssh2.so.1 (0xb76de000)
librt.so.1 => /lib/librt.so.1 (0xb76d5000)
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0xb7673000)
libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0xb74ad000)
libz.so.1 => /lib/libz.so.1 (0xb7495000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb747a000)
libc.so.6 => /lib/libc.so.6 (0xb72d4000)
libdl.so.2 => /lib/libdl.so.2 (0xb72cf000)
/lib/ld-linux.so.2 (0xb7771000)
In my distro, the change they made was that /lib is now a symlink to /usr/lib: http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/
EDIT
I tried what DaveRandom suggested here...
[root http]# php -r " echo (file_exists('/usr/lib/php/modules/curl.so')) ? 'It exists.' : 'It doesn\'t e.'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: file_exists(): open_basedir restriction in effect. File(/usr/lib/php/modules/curl.so) is not within the allowed path(s): (/srv/http/:/home/:/tmp/:/usr/share/pear/) in Command line code on line 1
Warning: file_exists(): open_basedir restriction in effect. File(/usr/lib/php/modules/curl.so) is not within the allowed path(s): (/srv/http/:/home/:/tmp/:/usr/share/pear/) in Command line code on line 1
It doesn't exist.
It failed because it didn't allow access to that path via the ini, so I reconfigured it and tried again...
[root http]# php -r " echo (file_exists('/usr/lib/php/modules/curl.so')) ? 'It exists.' : 'It doesn\'t exist.'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
It exists.
Freaky thing though is that JSON is actually working...
[root m]# php -r " echo (extension_loaded('json')) ? 'It is loaded' : 'It is not loaded'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
It is loaded
I guess the question is, what would cause cURL to work on command line, the module file to be there, but fail to load the extension via Apache PHP.
Then on the other hand what would cause JSON to give a warning, but still actually load?
Anybody know what the heck this could be?
Thanks
Alrighty, I found a work around. It's basically just to downgrade from cURL 7.27.0-1 to 7.26.0-1, which kind of sux, but it works:
I think this issue was unique to ArchLinux, but this will fix it (if you're an ArchLinux user like me).
mkdir /tmp/pacman_build
cd /tmp/pacman_build
cp /var/cache/pacman/pkg/curl-7.26.0-1-`uname -m`.pkg.tar.xz .
tar -xJf curl-7.26.0-1-`uname -m`.pkg.tar.xz
LD_PRELOAD=/tmp/pacman_build/usr/lib/libcurl.so pacman -U /var/cache/pacman/pkg/curl-7.26.0-1-`uname -m`.pkg.tar.xz
Please note, this requires you to recently have version 7.26.0-1 of curl in your package manager cache. If this fails, check /var/cache/pacman/pkg for another version of curl. If you don't have one in there, you'll have to find one.