MySQL, Apache, and PHP aren't talking, but they should already be talking

November 15, 2004 2:34 PM

MySQL, Apache, and PHP:
I can pull a phpinfo and it says that both mysql and dbx functions are compiled in and enabled, but when I run mysql_connect or dbx_connect, it can't connect. Apache and PHP work together and I can get into MySQL and do stuff via client. How can I make them talk when everything else I have says that they should already be talking?

I installed and updated everything via Fedora Core 3's yum command, so it should all be configured with the right stuff in the right places.
It's driving me nuts -- it all *looks* like it should work, but it doesn't.

posted by SpecialK to Computers & Internet (16 answers total)

What error is mysql_connect() throwing when you attempt to connect? If it's not very informative, try echo mysql_error(); immediately after the connection attempt.
posted by Danelope at 2:38 PM on November 15, 2004

What Danelope said.

Also: if the mysql command line client works and PHP doesn't, PHP is probably looking in the wrong place, or MySQL isn't making itself available correctly (not recalling exactly how the MySQL client itself operates, I know that the MySQL server will either listen on a network port, or use a UNIX socket file, usually in /var or /tmp).

For example, MySQL may be using the UNIX sockets, but PHP is looking on the network port (3306 I think), or vice versa.
posted by cyrusdogstar at 2:46 PM on November 15, 2004

Have you installed the php-mysql rpm?
posted by Caviar at 2:47 PM on November 15, 2004

Response by poster: It's not returning *any* errors except for the "false" from the connection function, danelope. That's the problem, it's not even talking to MySQL to give me a "bad password" or something else.
posted by SpecialK at 2:48 PM on November 15, 2004

Response by poster: I have the php-mysql rpm installed, installed everything at the same time ... phpinfo() looks fine to me.

It's connecting via unix socket, or at least it's supposed to, and both phpinfo() and mysql think the socket should be in /var/lib/mysql/mysql.sock ... which is where it is.

I've already tried all the usual things, I've been using PHP/MySQl/Apache for about three years. I've just always compiled the whole shootin' match myself on Slackware... I've never used this newfangled RPM thing that all the kids these days are using.
posted by SpecialK at 2:52 PM on November 15, 2004

Response by poster: Oh, and versions are 3.23.58 (yes, old, but ... that's what most distros are releasing, and all of my existing projects use) and PHP is 4.3.9 in case that matters.
posted by SpecialK at 2:56 PM on November 15, 2004

So what did mysql_error() display? Anything?
posted by Voivod at 3:33 PM on November 15, 2004

Response by poster: mysql_error didn't return anything, but in the apache error logs php threw an error that just didn't print to screen. It was the usual "cannot connect via mysql socket" error, but everything seems to be in the right spot for it to connect and the code itself is good

The only thing I've noticed that's weird is that mysqld is running as user # 27 with no info in /etc/passwd for user # 27. However, all other information in the /var/lib/mysql directories is chown'd to user 27 and the databases work fine with the mysql client.
posted by SpecialK at 3:56 PM on November 15, 2004

Perhaps your webserver doesn't have permission to open the socket? Make sure that 'other' users have read and write permission (i.e. chmod o+rw) on the socket and execute permission on all its parent directories (i.e chmod o+x).
posted by boaz at 5:43 PM on November 15, 2004

Response by poster: Yeah, the socket and parent directories were 777.
Apparently this is a common problem among noobs. On the fedora irc channel, there were three of us who couldn't get it to work. The devs all had it working, so they blew us off as n00bs. I hate being blown off that way; I've been using linux since 2.x kernels were a New Big Thing and have compiled more apps myself than most fedora devs have had diapers changed. I was looking to use a "modern" distro with robust and centralized package management because it's tough to admin more than a few of my trusted Slack servers unless you have a full-time sysadmin, so I'll look at Debian next.

I'm a PHB now, so I naturally take on some of the attributes of a newbie, but it still rankles that I couldn't get something this simple working, and that the fedora devs are so willing to blow off so many people that have a common problem.
posted by SpecialK at 6:24 PM on November 15, 2004

I've been having decent luck with Mandrake, but I really am a n00b.
posted by yerfatma at 6:55 PM on November 15, 2004

Response by poster: Yeah, but unfortunately Mandrake isn't very appropriate for a server environment. :-P
posted by SpecialK at 7:25 PM on November 15, 2004

What host are you passing to the mysql_connect() function? Try passing in a couple of different strings for the server, like "127.0.0.1:3306" (to test the TCP/IP socket) or ":/var/lib/mysql/mysql.sock" (to test explicitly setting the socket path) and see if either of those work.
posted by boaz at 8:57 PM on November 15, 2004

Response by poster: the socket path is explicitly set in the php.ini file... but yeah, either accessing it from the loopback interface via tcp/ip or via the socket borks. My guess is that it's something in the php-mysql binary that's distributed with the FC3 distro that's borked.
posted by SpecialK at 9:46 PM on November 15, 2004

Response by poster: (And I'd do a workaround or build my own rpm to get around that, but the whole purpose of the exercise of using a 'modern' distro like fc3 instead of my usual cro-magnon, rock-solid slackware was the package management and the ease of managing updates across several servers. Until I can afford to hire a linux sysadmin, I'm going to be managing my server closet myself.)
posted by SpecialK at 9:47 PM on November 15, 2004

unfortunately Mandrake isn't very appropriate for a server environment

How come?
posted by yerfatma at 4:05 AM on November 16, 2004