I have PHP 5.3.3 installed on Centos 6.4 with the memcached.so extension, and httpd is running with version 2.2.15-26. Here is my index.php:
$mc = new \Memcached();
$mc->addServer('127.0.0.1', 11211);
$mc->set("test", "blah");
var_dump($mc->getResultCode());
var_dump($mc->getResultMessage());
var_dump($mc->get("test"));
die;
When I run it from the command line, it works. I get the following:
10:22:33 $ php index.php
int(0)
string(7) "SUCCESS"
string(4) "blah"
The memcache server also works from telnet. However, when I run index.php from the web, it fails. I get the following (from viewing webpage source):
int(47)
string(51) "SERVER HAS FAILED AND IS DISABLED UNTIL TIMED RETRY"
bool(false)
Short of re-installing my OS and trying different versions of crap, can anyone explain what might cause this issue?
Is it an SELinux problem ? Cli can access to Memcached but daemon no. Try this :
getenforce to know if you have SELinux enabled
setenforce 0 to disable it
reboot
Retry your test
If is good, You must configure Apache to access to Memcached.
I have similar issue on CentOS and what I found it I am running SELinux which prevent httpd to connect to memcached. You need to set below,
# setsebool -P httpd_can_network_memcache 1
# getsebool httpd_can_network_memcache
httpd_can_network_memcache --> on
Please ensure that your memcache service should bind all IPs. Default value is 127.0.0.1. change it to 0.0.0.0 for supporting all defined Ips. In additional, don't forget to control your iptables or firewall.
I had this problem in WAMP 2.4, running a simple Memcache test script worked from the command line, but not in the browser.
The answer turned out to be stunningly mundane: WAMP had two php.ini files, and I was editing the wrong one.
E.g. Apache used this one: c:\wamp\bin\apache\Apache2.4.4\bin\php.ini
WAMP also had this one: c:\wamp\bin\php\php5.4.12\php.ini
Putting the extension=php_memcache.dll in the correct .ini file fixed things.
My clue something like this was the problem was that phpInfo()'s loaded config file reported different values in the two cases.
I had exactly the same issue as described by the OP. It turned out that the problem was caused by the server list the memcached extension maintains internally. My code was something like:
$serversList = $memcached->getServerList();
if (empty($serversList)) {
$memcached->addServer($host, $port);
}
My initial call to the testing script was done with a wrong value for $port. The call was done from web (apache) not from cli. After i corrected the port and i ran the code again, it was skipping the 'if' and used the existing servers list which was flawed and so it failed again.
Seeing the failure from the web i tested with the cli and it was working perfectly. In the cli the servers list was different from the one in the web. In fact, the server list was empty at each start of the script, even if my script was setting it with each run. Yet it was persisting between calls on the web.
Anyway, after clearing the servers list on the web and setting the correct server, it worked as expected from the web too.
When I look at examples I see it being used without the namespace "\" modifier. Try without it maybe?
http://www.php.net/manual/en/memcache.examples-overview.php
<?php
$memcache = new Memcache;
$memcache->connect('localhost', 11211) or die ("Could not connect");
Related
I'm using WAMP. In the past weeks I struggled a lot to make php and curl work behind a corporate proxy, finally I did it: Apache behind corporate proxy
The problem is that now I can't make them work at home! (of course initially they were working at home without proxy). When I run a CURL command from php I get the following error: Curl error: Failed to connect to localhost port 3128
I removed all the environment variable https_proxy and http_proxy, on apache I removed the "proxy_module", on IE I removed the proxy, now when I run the following command there are no results:
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | find /i "proxyserver"
It seems that CURL is taking the proxy configuration from somewhere in the environment variable, in fact if I add the applicative code:
curl_setopt($ch,CURLOPT_PROXY, '');
then everything is working fine (but I don't want to change the applicative code). Where else can I look for the proxy confing?
Thanks very much
I'm debugging my PHP app on CentOS7 using Apache.
My application is a Web GUI to manage the Torque batch system and I used the qmgr, which is a command line tool provided by Torque to do the management work.
Because only the root user can execute the qmgr and the Apache server cannot be running as root user, I have written a C program as a wrapper for anyone to execute commands as root user.
But the PHP application always give the following output:
socket_connect_unix failed: 15137
qmgr: cannot connect to server (errno=15137) could not connect to trqauthd
This means the PHP app cannot raise a socket connection to connect the Torque server.
Here is some additional information:
The command called by the PHP application can be executed correctly in the shell
The same PHP app can be executed correctly on a CentOS6 server with Apache
SELinux and the firewall are disabled
I have tried the two versions (5.1 and 4.10) of Torque, the result is the same
Apache and PHP are used with the default RPM's of CentOS7.
I thought there are some new security limits that maybe influence Apache on the CentOS7 server.
Please give me some suggestions, thank you!
I had the exact same problem.
The cause is that newer Apache.httpd versions default to having the systemd property PrivateTmp set to true. This causes the httpd service to see a private /tmp directory that is actually mapped to some other location in the file system, instead of the real /tmp directory. PHP, running in the Apache process, has the same /tmp directory as the Apache service, and so do any processes forked from PHP (e.g. using exec or system etc). So when PHP calls qsub (etc), that too will see the private /tmp directory.
This causes the error you mentioned because qsub internally uses the unix socket /tmp/trqauthd-unix to communicate with trqauthd. But qsub sees the "fake"/private /tmp directory instead of the real one, so it doesn't find the socket.
This explains why the command works when you run it manually in a console--in that case, qsub sees the real /tmp directory, as opposed to the private one it sees when forked from PHP (running the Apache service).
One solution is to simply change the PrivateTmp property in the file httpd.service from true to false. You can find this file under the /etc/systemd directory. The subfolder it is in probably depends on the linux distribution, so use the find command to locate it:
find /etc/systemd -name httpd.service
This really helped me!
I have been struggling a lot having a php script using exec()-command. For some reason I got permission denied. Having tried vary many things, including running my scripts in shell as the www-data user, but with no success, this was finally the solution to my problem.
BTW, for Ubuntu the apache service config file is located at cat /etc/systemd/system/multi-user.target.wants/apache2.service
I use composer on a network where the only way to access the internet is using HTTP or socks proxy. I have http_proxy and https_proxy environment variables. When compose tries to access HTTPS URLs I get this:
file could not be downloaded: failed to open stream: Cannot connect to HTTPS server through proxy
As far as I know the only way to connect to a https website is using a connect verb. How can I use composer behind this proxy?
If you are using Windows, you should set the same environment variables, but Windows style:
set http_proxy=<your_http_proxy:proxy_port>
set https_proxy=<your_https_proxy:proxy_port>
That will work for your current cmd.exe. If you want to do this more permanent, y suggest you to use environment variables on your system.
If you're on Linux or Unix (including OS X), you should put this somewhere that will affect your environment:
export HTTP_PROXY_REQUEST_FULLURI=0 # or false
export HTTPS_PROXY_REQUEST_FULLURI=0 #
You can put it in /etc/profile to globally affect all users on the machine, or your own ~/.bashrc or ~/.zshrc, depending on which shell you use.
If you're on Windows, open the Environment Variables control panel, and add either a system or user environment variables with both HTTP_PROXY_REQUEST_FULLURI and HTTPS_PROXY_REQUEST_FULLURI set to 0 or false.
For other people reading this (not you, since you said you have these set up), make sure HTTP_PROXY and HTTPS_PROXY are set to the correct proxy, using the same methods. If you're on Unix/Linux/OS X, setting both upper and lowercase versions of the variable name is the most complete approach, as some things use only the lowercase version, and IIRC some use the upper case. (I'm often using a sort of hybrid environment, Cygwin on Windows, and I know for me it was important to have both, but pure Unix/Linux environments might be able to get away with just lowercase.)
If you still can't get things working after you've done all this, and you're sure you have the correct proxy address set, then look into whether your company is using a Microsoft proxy server. If so, you probably need to install Cntlm as a child proxy to connect between Composer (etc.) and the Microsoft proxy server. Google CNTLM for more information and directions on how to set it up.
If you have to use credentials try this:
export HTTP_PROXY="http://username:password#webproxy.com:port"
Try this:
export HTTPS_PROXY_REQUEST_FULLURI=false
solved this issue for me working behind a proxy at a company few weeks ago.
This works , this is my case ...
C:\xampp\htdocs\your_dir>SET HTTP_PROXY="http://192.168.1.103:8080"
Replace with your IP and Port
on Windows insert:
set http_proxy=<proxy>
set https_proxy=<proxy>
before
php "%~dp0composer.phar" %*
or on Linux insert:
export http_proxy=<proxy>
export https_proxy=<proxy>
before
php "${dir}/composer.phar" "$#"
iconoclast's answer did not work for me.
I upgraded my php from 5.3.* (xampp 1.7.4) to 5.5.* (xampp 1.8.3) and the problem was solved.
Try iconoclast's answer first, if it doesn't work then upgrading might solve the problem.
You can use the standard HTTP_PROXY environment var. Simply set it to the URL of your proxy. Many operating systems already set this variable for you.
Just export the variable, then you don't have to type it all the time.
export HTTP_PROXY="http://johndoeproxy.cu:8080"
Then you can do composer update normally.
Operation timed out (IPv6 issues)#
You may run into errors if IPv6 is not configured correctly. A common error is:
The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out
We recommend you fix your IPv6 setup. If that is not possible, you can try the following workarounds:
Workaround Linux:
On linux, it seems that running this command helps to make ipv4 traffic have a higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
Workaround Windows:
On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).
Workaround Mac OS X:
Get name of your network device:
networksetup -listallnetworkservices
Disable IPv6 on that device (in this case "Wi-Fi"):
networksetup -setv6off Wi-Fi
Run composer ...
You can enable IPv6 again with:
networksetup -setv6automatic Wi-Fi
That said, if this fixes your problem, please talk to your ISP about it to try and resolve the routing errors. That's the best way to get things resolved for everyone.
Hoping it will help you!
according to above ideas, I created a shell script that to make a proxy environment for composer.
#!/bin/bash
export HTTP_PROXY=http://127.0.0.1:8888/
export HTTPS_PROXY=http://127.0.0.1:8888/
zsh # you can alse use bash or other shell
This piece of code is in a file named ~/bin/proxy_mode_shell and it will create a new zsh shell instance when you need proxy. After update finished, you can simply press key Ctrl+D to quit the proxy mode.
add export PATH=~/bin:$PATH to ~/.bashrc or ~/.zshrc if you cannot run proxy_mode_shell directly.
I have a strange issue. I'm trying to write a simple php webpage on my server, but mysql_connect() doesn't connect to any server, either local or otherwise. Here's where it gets strange. If I take the same php script and run it from the commandline, the script works. phpinfo() indicates that both the file (being run by apache) and the commandline (run as root) are calling the same version of php, mysql is loaded, and the php.ini is the same.
Furthermore, I'm running a MediaWiki installation on this same server, and it's using the mysqld installed locally and works just fine, so I'm completely at a loss as to why the code isn't working. The error I receive on runtime:
Can't connect to MySQL server on 'xxx.xxx.xxx.xxx' (13)
(The IP is x'd out for the privacy of the owner of the server I'm connecting to)
What operating system are you trying to connect from? It sounds like it may be an SELinux issue.
With SELinux, you can usually allow apache to make network connections by using
/usr/sbin/setsebool httpd_can_network_connect 1
OR
/usr/sbin/setsebool httpd_can_network_connect true
An operating system without SELinux may have a similar protection mechanism.
Check basic network connectivity. ping xxx.xxx.xxx.xxx from the webserver. If that doesn't work, check the network configuration on both ends.
Try running mysql from the webserver: mysql -h xxx.xxx.xxx.xxx -u user -p If that can't connect, track the cause: it could be a SELinux issue on either end (check the security log), or maybe there is an alias in /etc/hosts? Also enable verbose messages with -v -v -v on the mysql command line.
Check that the user is allowed to log on using the user administration feature of mysql.
I am using this php code:
exec("unrar e file.rar",$ret,$code);
and getting an error code of illegal command ie 127 ... but when I am using this command through ssh its working ... because unrar is installed on the server ... so can anyone guess why exec is not doing the right stuff?
Try using the direct path of the application (/usr/bin/unrar of whatever), it sounds like php can't find the application.
If you have chrooted apache and php, you will also want to put /bin/sh into the chrooted environment. Otherwise, the exec() or passthru() will not function properly, and will produce error code 127, file not found.
Since this comes up as a top answer in google, I wanted to share my fix:
The simple fix I had was to disable safe_mode in the php.ini file
; Safe Mode
; http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode
safe_mode = Off
thanx all for your response!!
I tried this
//somedir is inside the directory where php file is
chdir("somedir");
exec("/home/username/bin/unrar e /home/path/to/dir/file.rar");
and now it returned no exit code ... oher commands are doing file .. i tried mkdir etc .. :s
Just in case somebody else still gets this problem, take a look at the post here:
http://gallery.menalto.com/node/2639#comment-8638
Quote:
I found the problem. The problem was my security-paranoid OpenBSD. When upgrading from 3.1 to 3.2 they added:
Apache runs chroot'd by default. To disable this, see the new -u option.
The chroot prevented Apache from accessing anything outside of a directory, so I moved everything into the apache directory including netpbm. Everything was accessible and executable, but I guess it was still in some sort of "safe mode" because the exec() always returned 127.
Anyway, running httpd with the -u option went back to the less secure non chroot'd apache startup, which allowed the exec() to work again.
ohkiee guyz thanx ... and yes there might be some errors with $PATH ... but with given full path its working :)
exec("/home/user/bin/unrar e /home/user/xxx/yyy/file.rar");
I did not find the solution for my problem of the same type so sharing what was the cause of it in my Linux setup.
For whatever reason I needed an apache module loaded before other modules and so apache was started with LD_PRELOAD. As exec inherits the environment of the parent process LD_PRELOAD was used for starting the exec-ed program (through sh). Now the preloaded module uses some bindings to apache functions and of course they are not to be present in sh. The result of the php exec was an exit status of 127. The solution was to have in my php file a putenv("LD_PRELOAD") that gets executed before any exec calls.