306291 - DBI connect('host=localhost;database=bugs;port=3306','bugs',...) failed:

Status: RESOLVED INVALID

(Bugzilla :: Database, defect)

Description

[Satish Thumar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I have cleared all the test of installing the bugzilla and i have sucessfully
install all the perl module. But when i connect to it, it will produce the
follwing error. The version of mine is  Bugzilla  Version 2.18.3  

DBI connect('host=localhost;database=bugs;port=3306','bugs',...) failed: Can't
connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) at
/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/DBI.pm line 609
	DBI::__ANON__('undef', 'undef') called at
/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/DBI.pm line 666
	DBI::connect('DBI', 'DBI:mysql:host=localhost;database=bugs;port=3306', '', '',
'HASH(0xfef410)') called at Bugzilla/DB.pm line 146
	Bugzilla::DB::_connect('DBI:mysql:host=localhost;database=bugs;port=3306')
called at Bugzilla/DB.pm line 138
	Bugzilla::DB::connect_main() called at Bugzilla.pm line 143
	Bugzilla::dbh('Bugzilla') called at Bugzilla.pm line 157
	Bugzilla::dbwritesallowed('Bugzilla') called at globals.pl line 355
	main::GetVersionTable() called at /var/www/html/bugzilla/query.cgi line 210
 at Bugzilla/DB.pm line 146


when i run the checksetup.pl
it will give me follwing
Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.56
Checking for             CGI (v2.93)   ok: found v3.11
Checking for    Data::Dumper (any)     ok: found v2.121_02
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.36)   ok: found v1.48
Checking for      DBD::mysql (v2.1010) ok: found v3.0002
Checking for      File::Spec (v0.82)   ok: found v3.09
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.08)   ok: found v2.14
Checking for      Text::Wrap (v2001.0131) ok: found v2001.09292

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.28
Checking for     Chart::Base (v1.0)    ok: found v2.3
Checking for     XML::Parser (any)     ok: found v2.34
Checking for       GD::Graph (any)     ok: found v1.43
Checking for GD::Text::Align (any)     ok: found v1.18
Checking for     PatchReader (v0.9.4)  ok: found v0.9.5

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for    MySQL Server (v3.23.41) ok: found v4.1.13-standard

Populating duplicates table...


Reproducible: Always

Comment 1

[Olav Vitters]

For some reason Bugzilla cannot connect to your MySQL server. This is not a bug
in Bugzilla, but something to do with your MySQL setup. Bugzilla.mozilla.org
tracks bugs in / enhancements for Bugzilla. As report is not a bug within
Bugzilla I'm closing this bug. For support options please see:
  http://www.bugzilla.org/support/

Suggest to verify the MySQL database is running. Also try replacing the hostname
'localhost' with '127.0.0.1'. Please feel free to report any further bugs you find.

Comment 2

[John Volpe]

Please re-open this bug...... 
 
I too have encountered this problem.  This may be a MySQL problem however it 
affects bugzilla, I AM able to login with the bugzilla account information 
from :     
localhost using $ mysql -h localhost -u bugs -p     
localhost using $ mysql -h 127.0.0.1 -u bugs -p     
localhost using $ mysql -h 192.168.0.7 -u bugs -p     
remote using    $ mysql -h 192.168.0.7 -u bugs -p    
    
We use the same MySQL server for other applications - so yes the server is    
running and configured correctly.    
    
In addition the checksetup.pl run from the localhost indicates that the    
connection is OK.    
    
This occurred sometime after upgrading the server to Fedora Core 4.  We have    
been running bugzilla successfully on this same system under Fedora Core 2 for    
a year now.    
    
The root of the question is "What is different about the way checksetup.pl and    
globals.pl connect to the database ?"    
    
I will continue to investigate this problem and report anything I find.    

Comment 3

[Max Kanat-Alexander]

It's a support issue, actually, though, not a bug. At least, I suspect so. Check
where your mysql.sock file actually is -- you may need to set $db_sock in
localconfig.

Comment 4

[John Volpe]

I'm tracking this issue as an apache configuration issue.  So far I have : 
 
1. Bounced mysql access off another server (forwarded via xinetd).  This forces 
bugzilla to use TCP/IP for communications with the server. 
 
2. Snipped the connect code from Bugzilla/DB.pm and wrapped it into a test CGI 
script.   
 
I can connect to mysql from anywhere by using the secondary server forwarded to 
the primary server. 
 
If I run the test.cgi script from the command line as root, the connect 
succeeds . 
 
If I run the test.cgi from the command line as user apache, the connect 
succeeds. 
 
If I run the test.cgi script from the apache server, it fails with "unable to 
create the TCP/IP socket" in DBI.pm 
 
There is something wrong with the way apache is setting up the environment or 
with the way the bugzilla virtual server is setup. 
 
Below is my bugzilla virtual server section from http.conf. 
 
NameVirtualHost 192.168.0.7 
 
<VirtualHost 192.168.0.7> 
	DocumentRoot /var/www/html/bugzilla 
	ServerName bugzilla.benthos.com 
	<Directory "/var/www/html/bugzilla/"> 
                Options +ExecCGI  
 		AddHandler cgi-script .cgi 
		AllowOverride Limit 
		allow from all 
		order allow,deny 
		DirectoryIndex index.cgi 
	</Directory> 
	UseCanonicalName off 
</VirtualHost> 
 

Comment 5

[John Volpe]

.......... SELinux ..................  
  
SELinux was enabled for my server and the boolean httpd_can_network_connect was  
set inactive.  This prevented apache from making a network connection.  
  
Use $ setsebool -P httpd_can_network_connect=1  
 
All is well, I hope this helps the original reporter.......... 

Comment 6

[John Volpe]

Additional information.... 
 
The previous comment allows access via the network (use network address of 
localhost instead of localhost) .  I had to disable all SELinux activities to 
use the local socket interface to MySQL. 
 
$ setsebool -P httpd_disable_trans=1   
 
This command will disable all SELinux auditing on the httpd daemon.