Lokale Verbindung zu MySQL über TCP nicht möglich - Verbindungstimeout - Ubuntu 9.04

Lokale Verbindung zu MySQL über TCP nicht möglich - Verbindungstimeout - Ubuntu 9.04

Ich verwende Ubuntu und versuche, Tomcat über JDBC mit meiner MySQL-Datenbank zu verbinden.

Es hat vorher funktioniertNach einem Neustart kann die Instanz jedoch keine Verbindung mehr herstellen.

  • Sowohl Tomcat 6 als auch MySQL 5.0.75 befinden sich auf derselben Maschine
  • Verbindungszeichenfolge: jdbc:mysql:///localhost:3306
  • Ich kann über die Kommandozeile eine Verbindung zu MySQL herstellen, indem ich den mysqlBefehl
  • Die Datei my.cnf ist ziemlich standardmäßig (auf Anfrage erhältlich) und hat die Bindungsadresse: 127.0.0.1
  • Ich kann keine Telnet-Verbindung zum MySQL-Port herstellen, obwohl Netstat angibt, dass MySQL zuhört.
  • Ich habe eine IpTables-Regel zur Weiterleitung von 80 -> 8080 und keine mir bekannte Firewall.

Ich bin ziemlich neu hier und bin mir nicht sicher, was ich sonst noch testen soll. Ich weiß nicht, ob ich in etc/interfaces nachschauen sollte und ob ich getan habe, wonach ich suchen soll. Es ist komisch, weil es früher funktioniert hat, aber nach einem Neustart ist es nicht mehr da, also muss ich etwas geändert haben.... :).

Mir ist klar, dass ein Timeout bedeutet, dass der Server nicht antwortet, und ich gehe davon aus, dass dies daran liegt, dass die Anfrage nicht durchkommt. Ich habe MySQL manuell über apt-get und Tomcat installiert.

MySqld-Prozesse

root@88:/var/log/mysql#  ps -ef | grep mysqld
root     21753     1  0 May27 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql    21792 21753  0 May27 ?        00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root     21793 21753  0 May27 ?        00:00:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
root     21888 13676  0 11:23 pts/1    00:00:00 grep mysqld

Netstat

root@88:/var/log/mysql# netstat -lnp | grep mysql
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      21792/mysqld
unix  2      [ ACC ]     STREAM     LISTENING     1926205077 21792/mysqld        /var/run/mysqld/mysqld.sock

Spielzeug-Verbindungsklasse

root@88:~# cat TestConnect/TestConnection.java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class TestConnection {

  public static void main(String args[]) throws Exception {
    Connection con = null;

    try {
      Class.forName("com.mysql.jdbc.Driver").newInstance();
      System.out.println("Got driver");
      con = DriverManager.getConnection(
                "jdbc:mysql:///localhost:3306",
                "uname", "pass");
      System.out.println("Got connection");

      if(!con.isClosed())
        System.out.println("Successfully connected to " +
          "MySQL server using TCP/IP...");

    } finally {
        if(con != null)
          con.close();
    }
  }
}

Ausgabe der Spielzeugverbindungsklasse

Hinweis: Dies ist derselbe Fehler, den ich von Tomcat bekomme.

root@88:~/TestConnect# java -cp mysql-connector-java-5.1.12-bin.jar:. TestConnection
Got driver
                Exception in thread "main" com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 1 milliseconds ago. The driver has not received any packets from the server.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1122)            
        at TestConnection.main(TestConnection.java:14)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1122)
        at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:344)
        at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2181)
        ... 12 more
Caused by: java.net.ConnectException: Connection timed out
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        ... 13 more

Telnet-Ausgabe

root@88:~/TestConnect# telnet localhost 3306
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out

Iptables

HINWEIS: Ich hatte eine Regel für NAT eingerichtet, diese aber entfernt und das Problem besteht weiterhin.

root@88:~# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

root@88:~# iptables -t nat -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Befehl zum Einrichten von iptables

iptables -t nat -I PREROUTING --src 0/0 --dst 88.198.31.14 -p tcp --dport 80 -j REDIRECT --to-ports 8080

Ich habe die Regel, die dieses Setup für das NAT erstellt hat, inzwischen entfernt, daher ist dieser Befehl nicht relevant, sofern er keine Nebeneffekte hat.

UPDATE - Ich kann localhost nicht anpingen

IP-Adresse

root@88:~/TestConnect# ip a
1: lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.1/32 scope host venet0
    inet 88.198.31.14/32 scope global venet0:0

ip r

root@88:~/TestConnect# ip r
    192.0.2.1 dev venet0  scope link
    default via 192.0.2.1 dev venet0

IP-Regel

root@88:~/TestConnect# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

ping -c 1 lokaler Host

root@88:~/TestConnect# ping -c 1 localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.

--- localhost.localdomain ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Katze /etc/hosts

root@88:~/TestConnect# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
# Auto-generated hostname. Please do not remove this comment.
88.198.31.14 88.198.31.14  88 88

ifconfig

root@88:/var/log/mysql# ifconfig
venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:144432 errors:0 dropped:0 overruns:0 frame:0
          TX packets:153825 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:37896766 (37.8 MB)  TX bytes:28722595 (28.7 MB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:88.198.31.14  P-t-P:88.198.31.14  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Ich denke, wir haben den Fehler dank pQd eingegrenzt. Ich muss nachlesen, was das alles bedeutet und warum kein Ping an den lokalen Host möglich ist.

Antwort1

Sind Sie absolut sicher, dass es keine Iptables-Regel gibt, die TCP/3306-Verkehr verhindert? Versuchen Sie Folgendes als vorübergehende Problemumgehung:

iptables -I INPUT -p tcp --dport 3306 -i lo -j ACCEPT
iptables -A OUTPUT -p tcp --sport 3306 -o lo -j ACCEPT

Oder vielleicht regeln Ihre NAT-Regeln etwas mehr, als Sie erwarten?

ok – Ihr Loopback ist nicht nur ausgefallen, sondern hat auch keine Bindung an 127.0.0.1. Fügen Sie zu /etc/network/interfaces hinzu:

auto lo
iface lo inet loopback

und ... warum um Himmels Willen haben Sie es an vnet0 gebunden? Entfernen Sie es von dort.

Schnelle, einmalige Korrektur der Befehlszeile:

ip a d 127.0.0.1/32 dev venet0
ip a a 127.0.0.1/32 dev lo
ip link set dev lo up

verwandte Informationen