I'm facing a perplexing problem. I've completed a jsf web app that utlizes hibernate and infinispan with Tomcat7 and tomcat-jdbc-pool as the connection pool provider.
It is being deployed to a Linode cluster w/ 2 nodes -- one database server and one production server.
I can run the app on my local environment using the exact same copy of Tomcat7 (I literally tarred the tomcat directory and promoted it to the server to debug this error) -- even when connected to the live database instance. Everything runs fine.
When I attempt to run the application from the production server I get a MySQLIO error:
Caused by: java.net.ConnectException:
Connection refused
Looking further up in the logs i see:
The last packet sent successfully to
the server was 1 milliseconds ago. The
driver has not received any packets
from the server.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
I can connect from the command line on the prodapp server just fine -- even using tcp:
mysql -h db01 -u user -p --protocol=tcp
But it just won't work running inside the Tomcat container. I've tried all kinds of things but I'm really stumped. It just seems strange that I can connect to the database server using the same copy of Tomcat7 locally but when deployed to production the same copy of tomcat7 can't connect -- even though I can connect from the command line on that production server ... I'm stumped.
Any help is greatly appreciated.
EDIT: Solved my problem after wasting too much good life on it. The answer was I'm stupid. Thanks to everyone who tried to help. I have the app moded w/ a dev and live mode and the connection pool was reading the dev mode this whole time. What really made it confusing is that the sessionfactory was moded to live so it would actually reach the live database and initialize a connection when it started up so i could see it connecting (and running meta data queries in the mysql log), but when it actually went to grab a connection from infinispan it blew up. Oh well -- at least it's working now. Thanks again.
If you're connecting to your MySQL database server from a different box, then you need to explicitly grant permission for that user account to connect from that IP.
You can do this whilst in the command line:
GRANT ALL PRIVILEGES ON *.* TO 'username'#'ip_address'
EDIT: Granting all permissions on all tables generally isn't required, be specific about what permissions you want to grant (http://dev.mysql.com/doc/refman/5.1/en/grant.html)
To see what permissions you currently have:
USE mysql;
SELECT * FROM users;
My apologies if I'm patronising you, just that this is the most common problem that I come across.
Related
I have a Laravel app on digital ocean and it runned fine for about 4 days now.
But today when I woke up it suddenly couldn't connect to the DB.
Also when I try to login in phpmyadmin it says
2002 - Connection refused — The server is not responding (or the local server's socket is not correctly configured).
I tried changing localhost to 127.0.0.1 in the config-db.php file and restarting apache, because some guy in their forums had the same problem and said that it fixed it for him, but for me it had no effect.
Other errors I see are
mysqli_real_connect(): (HY000/2002): Connection refused
Connection for controluser as defined in your configuration failed.
mysqli_real_connect(): (HY000/2002): Connection refused
I am certain that no configuration files have been changed, it just stopped working, why that might be, and how to prevent it in the future ?
The OS is Ubutnu 18.04.13 (if it matters)
It would appear as if your MySQL daemon is no longer running.
The hints here are that the Laravel app is not able to reach the MySQL server, and that phpMyAdmin is also unable to reach the MySQL server.
You should look in the MySQL error log for hints. You may also find hints in your syslog, depending on how your system is configured. This could give you information about why the service has stopped. You might also find information in the systemd log, which can probably best be viewed with journalctl -u mysql -b.
You could verify that it's actually stopped with systemctl status mysql, even though it's difficult for me to think of a reason why it would be running correctly but not responding to any connection attempts.
Next, you should probably start the service again with sudo systemctl start mysql. If it fails to start, you'll see some information about why not with information about viewing the log file, which you can copy and paste in to your question to help us further with troubleshooting.
I have seen many stack overflows questions and some blogs tried workarounds, but nothings helped - hence re-posting the question with more details.
I am seeing the weird behaviour with MySQL and Python application, details are as follows:
1) My application works perfectly fine with MySQL (tried and tested on many platforms) but on this particular machine it fails to connect to MySQL.
structure of application is :
Windows service -> parent process -> Mysql(child process)
and when application tries to connect to MySQL it get this error:
ERROR 2013 , Lost connection to MySQL server at 'waiting for initial communication packet' - system error 0
I tried:
- connect_timeout=300
- skip-name-resolve=0
- firewall is OFF
- use 17.0.0.1, localhost , IP of machine to connect to but it still fails with same error.
2) Now the weird thing is -
If I manually follow all the steps which application does, It works perfectly fine, details are follows:
a) Start MySQL with same command (which application uses) with administrator privileges
mysql --default-file = xxx --basedir =xxx
b) Connect with same credentials ( -u root -P 6075 -h 127.0.0.1) and
It works perfectly fine, I double checked all the steps which application does, there is no difference between manually steps and application code.
AM I missing something here ? Any suggestions ?
MySQL version : 5.5.35
Python : 2.7
Base OS : Windows 2012 R2
Thanks in advance..
Found a reason - answering my question:
When I used to run MySQL from my application - it was running under system user privileges - so it used to pick "C:\WINDOWS\TEMP" as a temp directory- this directory was messed up - has lot of unnecessary files .. and MySQL was stuck while processing files under this directory...
But when I ran it manually under My administrator account it was using his temp directory... C:\Users\USER_NAME\AppData\Local\Temp and everything was working like magic...
To fix this permanently I changed tmp directory through MySQL conf file and now My Application runs like the Wind.... :)
[mysqld]
tmpdir = 'PATH_TO_THE_DIRECTORY'
I was getting this same error trying to set up a SQL Server Linked Server
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "DBLINKED".
OLE DB provider "MSDASQL" for linked server "DBLINKED" returned message "[MySQL][ODBC 8.0(w) Driver]Lost connection to MySQL server at 'waiting for initial communication packet', system error: 10060". (Microsoft SQL Server, Error: 7303)
You mentioned it in your initial question - the Connection Timeout was the issue for me.
The default is 0 - raised it to 300. I thought default of 0 would mean no timeout, but it's obviously something reasonably short, and I was trying to connect to a remote database on a slow internet connection. A lot of other question and answers out there relate to connecting within the same machine, so this error isn't reported much.
I think I've seen a variety of similar posts on this topic, but am still unable to resolve my issue, so I figured I'd post with my specifics.
I have an Amazon AWS Linux EC2 instance running Tomcat7 web server. On the same machine I am also running a MySQL5 server, but I am unable to get the Tomcat app to talk to the MySQL database.
My Java app on tomcat tries to connect to MySQL by reading from a properties file:
jdbc.mysql.host.path=jdbc:mysql://localhost/
jdbc.mysql.schema=prod
jdbc.mysql.username=root
jdbc.mysql.password=<password>
I am accessing the app from another system via web browser, but when the app tries to connect to the database I get the following error in catalina.out:
java.sql.SQLException: Access denied for user 'root'#'localhost' (using password: YES)
I'm pretty sure the issue has to do with permissions and communication between Tomcat and MySQL, because I've written a simple java program utilizing the same code to read the same properties file, and the connection is made successfully.
Here are some things I have attempted to remedy the issue:
change the owner of the properties file (currently owned by 'Tomcat')
ensured that user 'root' has been granted all privileges in MySQL
ensured that port 3306 (MySQL default port) is accessible by my test server
updated iptables made various modifications to /etc/my.cnf file
(tried to bind ip, but that didn't work)
I have a hunch that the issue may be related to the fact that I am trying to access the MySQL database using user 'root'. Even though I'm accessing it via localhost, the system may not support this because MySQL treats this as access from a separate host and (maybe?) root access from other hosts isn't allowed?
Any suggestions on things to try would be greatly appreciated...
I believe the issue was a combination of things.
Here are some items to consider that ultimately fixed it for me:
- making sure you were accessing the correct app via browser (I was using ROOT app, but trying to connect to another one)
- making sure a user exists in MySQL using 'Create User ....'
- making sure all privileges are granted on the database in question, for some reason granting all privileges on . wasn't working for me
I'm running a local copy of WordPress on XAMPP/WinXP for development, but would like to maintain a connection to the remote database. I keep getting "Error establishing database connection" no matter what I try.
On the same PC, I can connect to the remote mySQL DB using any number of mySQL clients, and on the mySQL side, the both the user and the database are set to accept incoming requests from any wildcard domain. I can also easily ping the remote database server from my PC (though I don't know how to do it from WITHIN XAMPP).
Is XAMPP its own little universe that can't reach through to the outside world? Or is there something I'm clearly overlooking that's not letting me connect?
Errors
Warning: mysql_connect() [function.mysql-connect]: Premature end of data (mysqlnd_wireprotocol.c:553) in C:\xampp\htdocs\dbtest.php on line 5
Warning: mysql_connect() [function.mysql-connect]: OK packet 1 bytes shorter than expected in C:\xampp\htdocs\dbtest.php on line 5
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication
Edit
Thanks to #Michael for suggesting I just create a simple connection script so I can get better insight into the actual error that's being thrown. This revealed that it had to do with the old_password setting in mySQL. See my Answer below for a full description of how to resolve this issue.
Here's the test script I put inside my xampp\htdocs folder and tested out:
<?php
$mysqli = new mysqli('my.server.address', 'user_name', 'password', 'database_name');
if ($mysqli->connect_error){
die ("Connect error: " . $mysqli->connect_error );
}
I'm not really clear on why this became an issue on my XAMPP installation, since I'm also running PHP 5.3.x on the server's local box and wasn't experiencing those issues there. However, it has to do with my mySQL server running in "old password" encryption mode. Newer versions of PHP won't allow those kinds of connections, so you need to update your mySQL server to use the newer password encryption. Here are the steps, assuming you have control over the mySQL server. If you don't, that falls out of the scope of my knowledge.
locate the configuration file for the mysql server called my.cnf. I found mine at /etc/my.cnf. You can edit it with sudo nano /etc/my.cnf
Look for a line that says old_passwords=1 and change that to old_passwords=0. You have now told the server that the next time it is run, and it is asked to encrypt a password using the PASSWORD() command, it use the new 41-character encryption rather than the 16-character 'old' style encryption
Now you have to restart your mysql server / service. YMMV, but on Fedora that was easily done with sudo service mysqld restart. Check your OS' instructions for restarting the mysql daemon or service
Now we have to actually edit our user table within mysql. So open up an interactive shell to mysql (on the server you can type mysql -uYourRootUsername -pYourRootPassword)
Change to the mysql database. This is the database that holds all the good stuff for server operation and authentication. You must have root access to work with this database. If you get an 'access denied' you're SOL. Sorry. use mysql; will switch to that database
Now we want to update the user that was giving you grief. Ultimately you'll probably want to update all your users, but for now, we're just focusing on the user that threw the error. update user set Password=password('YOUR_PASSWORD') where User='YOUR_USERNAME';
Now you just need to tell mysql to use the new password for authentication when that user attempts to connect. flush privileges;.
You should be good to go!
Having a bit of a problem with mysql...
Mysql 5.1 on windows 2008 server iis7
Site on windows 2003 server iis6
[sorry but can't move to linux kids! ;)]
In the process of shifting a site to a new server so I have moved the database 1st and connected the site to the new database. I tested the connection before moving but now the site is connecting to the new database I am having problems....
connecting via PDO the page hangs for an age before getting 'too many connections' error. Monitoring the server I see MANY threads of: 'unathenticated user' from the ip address of the host the site runs on.
I also see a thread for the connection with the correct user name in my config file and I am a total loss as to what is going on.
Any help would be very much appreciated
'unathenticated user' from the ip address of the host the site runs on
A stab in the dark, but this could be some script or process trying to connect to the database server with wrong or empty credentials.
Also, here's a report from somebody who had similar problems - in that case, it was the DNS lookup that caused the problem.
I had a similar situation on my setup where the database lived on a different host than
the webserver. I found the "unauthenticated users" were connections from the webserver
that were hanging on DNS lookups. Don't know if this is a mysql bug or a bug with my
firewall / other setup, but a couple of fixes I found were...
1) start mysql with --skip-name-resolve (you may have to change your mysql permission
tables to have the host's IP instead of hostname, including localhost)
or 2) add the connecting host to your /etc/hosts file.