MysqlSocketConfiguration: Difference between revisions
No edit summary |
m (3 revisions imported) |
(No difference)
|
Latest revision as of 15:15, 6 April 2016
`/tmp/mysql.sock'
/ (From http://dev.mysql.com/doc/mysql/en/Problems_with_mysql.sock.html) /
The default locations for the Unix socket file that the server uses for communication with local clients is `/tmp/mysql.sock'. This might cause problems, because on some versions of Unix, anyone can delete files in the `/tmp' directory.
On most versions of Unix, you can protect your `/tmp' directory so that files can be deleted only by their owners or the superuser (root). To do this, set the sticky bit on the `/tmp' directory by logging in as root and using the following command:
shell> chmod +t /tmp
You can check whether the sticky bit is set by executing ls -ld /tmp
. If the last permission character is t
, the bit is set.
Another approach is to change the place where the server creates the Unix socket file. If you do this, you should also let client programs know the new location of the file. You can specify the file location in several ways:
Specify the path in a global or local option file. For example, put the following lines in /etc/my.cnf:
[mysqld] socket=/path/to/socket [client] socket=/path/to/socket
See section 4.3.2 Using Option Files. Specify a --socket
option on the command line to mysqld_safe
and when you run client programs. Set the MYSQL_UNIX_PORT
environment variable to the path of the Unix socket file. Recompile MySQL from source to use a different default Unix socket file location. Define the path to the file with the --with-unix-socket-path
option when you run configure. See section 2.3.2 Typical configure Options.
You can test whether the new socket location works by attempting to connect to the server with this command:
shell> mysqladmin --socket=/path/to/socket version
Changing the MySQL socket RT uses
If you see an error in your web server's error log that looks like the following, you've probably run afoul of a deficiency in the DBI package. If your MySQL installation does not use (or you have reconfigured) the socket path DBI is expecting, RT will fail to connect to the database.
[Fri Jun 19 11:38:22 2009] [error] [client 192.168.1.1] FastCGI: server "/usr/local/rt3/bin mason_handler.fcgi" stderr: DBI connect('dbname=rt3;host=localhost','rt_user',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at /usr/perl5/site_perl/5.8.4/DBIx/SearchBuilder/Handle.pm line 106, referer: http://rt.myserver.com/requesttracking/
A fix is to set the environment variable MYSQL_UNIX_PORT
to identify the correct socket path so the Perl DBI package uses it. If you do not do this, it uses a built-in default value of /tmp/mysql.sock
. To implement this fix, adding the following line to your RT_SiteConfig.pm file changes the path to /usr/local/mysql/data/mysql.sock
:
# Fix for DBI using hard-coded MySQL socket location. $ENV{'MYSQL_UNIX_PORT'} = '/usr/local/mysql/data/mysql.sock';
Perhaps a simpler alternative may be to set the port number MySQL is using (default is 3306
):
Set($DatabasePort, '3306');
Don't forget to shut down and restart your web server after editing the configuration file.
- Ed Eaglehouse
Thanks Ed. This helped me resolve an issue that arose from an update. In my case the socket is not in the default location. RT was working but the cronjob for the dashboard email was not. It was kicking out the mentioned error. I thought perhaps if I changed mysql's configuration to the default I would get things up and running. But that caused the Apache server to fail to start. So I ended up going back to my non default and looking for a way to configure RT to use that location. I was just about to give up hope as I realized it wasn't RT but something else.
Neither the my.cnf change or setting the database port worked for me. The $ENV was the solution that worked.
- Kevin Gagel