Link to home
Start Free TrialLog in
Avatar of terabit_ca
terabit_ca

asked on

"Can't connect to MySQL server" through php/apache but command line php works.

I am trying to connect to a remote myql database server which is running centos 4.4 with mysql 5.0.27.

The website server is using apache (httpd 2.2.3), PHP 5.1.6 and Mysql Client API version 5.0.22.

Using a basic php script that does notthing but use mysql_connect to connect to the database server I get the following behaviour.

When run by accessing the php file through apache I get the error
"2003 : Can't connect to MySQL server on 'xx.xx.xx.xx' (13)"
where 2003 is the mysql_errno and the rest is mysql_error (I replaced my actal db server ip with xx for obvious reasons).

But If I run the same file from the command line "php connect.php" it connects to the db server no problem. As well if I run "mysql -h xx.xx.xx.xx -u ASDF -p" I can connect no problem as well. And just to be sure I have turned off iptables while trying to debug this problem.
I have setup a mysql db on the webserver and had no problem connecting to localhost... It is only a problem when trying to access a remote db server.

I have run the same php file from other servers and they have no problems connecting when run through apache (they have different centos versions but all 4 and above).

I have looked everywhere I can think to try and find some firewall like setting that is only active when running php/mysql through httpd but have come up empty. I hope there is just some simple httpd.conf setting that I have overlooked but at this point I am desperate to find it...

Thanks for reading.
Jamie
Avatar of richswyatt
richswyatt

I don't think we're having a firewall issue.

Can you show the code for how you're trying to do the mysql_connect...

I ran across a post the other day where the failure to connect was simply a semantics problem. I'd like to see what you have (of course leaving out vital information such as user/passwords)... :-)
Avatar of terabit_ca

ASKER

if(!($link = mysql_connect($serverName, $serverUsr, $serverPass, $serverDb, $serverPort))){
      echo mysql_errno()." : ";
      echo mysql_error()."<br>\n";
}

mysql_close($link);


But running it on other servers there is no problem so it can't be semantics...
Alright - fair enough. I didn't read that part. :-)

So - if I read right - you are able to connect to the same host, same DB, from other servers using the same script?

It is just from this one particular server that you cannot connect to this particular host/db, right?
Also - I misspoke about a firewall issue - but you did say that there are NO firewalls installed on this box or there are?
Yes that is correct. WIth this "webserver" I cannot connect to any remote db (through apache). But when the php file is run from shell it connects without a problem.
I have shut down iptable while trying to figure this out.
Did you compile Apache? If so - did you use --with-mpm=worker ?

Check your Apache configuration. If --with-mpm=worker was used in the compile - you will never be able to connect to remote MySQL servers. In that case Apache needs to be re-compiled without that flag.
'./configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/etc/httpd/conf/magic' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--without-odbc' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter'


This is what phpinfo() gives. No mention of mpm
Is this server Redhat?

Try opening SELinux->SELinux Service Protection and then disable the SELinux protection for myslq daemon
The web server is CentOS 5 and is in a data center. I only have remote access to it... Do you know how I would do that command from shell?
That doesn't apply then, I do not believe. Hmm.
Wow did that take me forever... I have waisted so much time trying to track this down. It turns out that it is a firewall like setting that is causing the problems. The short solution is to type "setenforce 0" to turn off SELinux. Up until now I didn't even know about the existance of SELinux

Here is a link that describes it (I have it going to the Q/A that gave me the above). There is more info in the link that will describe how to turn SELinux off at boot.
http://docs.fedoraproject.org/selinux-faq-fc3/index.html#id2826056

This same "feature" was responsible for another problem I was having on another server. In that case it was not allowing symbolic links pointing to seperate mounts from inside my document root. I looked forever at the "Options AllowSymLinks" scratching my head but running "setenforce 0" fixed that too...

I don't endorse just turning SELinux off but if you are having mysterious access problems try turning it off just to see if its the source.

Two major headaches gone :-)
Aha - I thought that was the problem - but I wasn't familiar enough with CentOS to know if SELinux applied. Sorry.
ASKER CERTIFIED SOLUTION
Avatar of Computer101
Computer101
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial