Bekomme MySQL nicht zum laufen

X

xor@ice

Grünschnabel
Hallo,

ich bekomme einfach den Webserver nicht hin... Apache2 und PHP habe ich schön hinbekommen. Läuft wunderbar. Nur MySQL will nicht. Bei der Installation kamen keine Fehler.

Ich habe Apache2, PHP und MySQL aus den src installiert.

Ich habe Ubuntu 8.10 Server als OS hier zur Verfügung.

Nun zu meinem Problem:

root@LinServ:/usr/local/mysql/bin# mysqladmin -u root password newpw
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/tmp/mysql.sock' exists!
root@LinServ:/usr/local/mysql/bin#

root@LinServ:/usr/local/mysql/bin# mysql -r root -p newpw
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
root@LinServ:/usr/local/mysql/bin#

So... Da ich ja schon vieles gelesen habe dazu, u.a. Ausagen wie "Läuft der MySQL denn überhaupt", habe ich mal das hier vorbereitet:

root@LinServ:/usr/local/mysql/bin# dir /tmp/
mysqld.sock
root@LinServ:/usr/local/mysql/bin#

root@LinServ:/usr/local/mysql/bin# ps xa | grep mysqld
5828 pts/0 S 0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/usr/local/mysql/data --pid-file=/usr/local/mysql/data/LinServ.pid
5945 pts/0 Sl 0:00 /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql --log-error=/usr/local/mysql/data/LinServ.err --pid-file=/usr/local/mysql/data/LinServ.pid --socket=/tmp/mysqld.sock --port=3306
5965 pts/0 S+ 0:00 grep mysqld

root@LinServ:/usr/local/mysql/bin# /etc/init.d/mysql restart
Shutting down MySQL
. *
Starting MySQL
. *
root@LinServ:/usr/local/mysql/bin#

root@LinServ:/usr/local/mysql/bin#cat /usr/local/mysql/data/LinServ.err
090401 17:44:30 [Note] Event Scheduler: Purging the queue. 0 events
090401 17:44:30 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete

090401 17:44:30 mysqld_safe mysqld from pid file /usr/local/mysql/data/LinServ.$
090401 17:44:32 mysqld_safe Starting mysqld daemon with databases from /usr/loc$
090401 17:44:32 [Note] Event Scheduler: Loaded 0 events
root@LinServ:/usr/local/mysql/bin#


MySQL habe ich so hier installiert:

groupadd mysql

useradd -g mysql -c "MySQL Server" mysql

cd /usr/local/src/mysql-5.1.33

chown -R root.root *

./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --with-mysqld-user=mysql --with-unix-socket-path=/tmp/mysql.sock

make && make install

./scripts/mysql_install_db

chown -R root:mysql /usr/local/mysql
chown -R mysql:mysql /usr/local/mysql/data

cp support-files/my-medium.cnf /etc/my.cnf
chown root:sys /etc/my.cnf
chmod 644 /etc/my.cnf

echo "/usr/local/mysql/lib/mysql" >> /etc/ld.so.conf
ldconfig

cp ./support-files/mysql.server /etc/init.d/mysql
chmod +x /etc/init.d/mysql

cd /usr/local/mysql/bin
for file in *; do ln -s /usr/local/mysql/bin/$file /usr/bin/$file; done

mkdir /usr/local/mysql/var
chown -R mysql:mysql /usr/local/mysql/var

edit into /etc/my.cnf:

[mysqld_safe]
socket = /tmp/mysqld.sock
nice = 0

[mysqld]
user = mysql
socket = /tmp/mysqld.sock
tmpdir = /tmp

changes in /etc/my.cnf:

change #skip-networking to skip-networking
change skip-federated to #skip-federated

Also wenn mir jmd helfen kann, dann wäre ich sehr froh :)

Ps: Ich habe nicht die möglichkeit den Paketmanager zu nutzen ;) Also fällt apt-get und die ganzen anderen Sachen weg ;)

Mfg Markus
 
1. Was mir beim Überfliegen so auffällt:

Can't connect to local MySQL server through socket '/tmp/mysql.sock'

vs.:

root@LinServ:/usr/local/mysql/bin# dir /tmp/
mysqld.sock

(Soll heißen, da ist ein "d" zuviel oder zuwenig, je nach Sichtweise)

2. Zeig auch mal die Ausgabe von

Code:
netstat -tulpen | grep  3306

3. Gibt es irgendeinen besonderen Grund, warum du einen Unix Domain Socket (a.k.a. IPC) verwendest und nicht einen "normalen" TCP / IP Socket?
 
Zuletzt bearbeitet:
MySQL benutzt beim Zugriff über localhost prinzipiell die Socket-Datei für den Zugriff. Es muss also nur der Socket-Pfad in der Client-Sektion der my.cnf korrigiert werden.
 
Hallo,

danke für Eure Hilfe. Ich habe nun das mysqld.sock überall angepasst und nun funktioniert auch alles.

root@LinServ:/home/linserv# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.33-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Nur ich hab den Fehler gestern einfach nicht gefunden. Hab wohl zu lange den ganzen Tag in das schwarz-weiße Fenster geschaut ;)

3. Gibt es irgendeinen besonderen Grund, warum du einen Unix Domain Socket (a.k.a. IPC) verwendest und nicht einen "normalen" TCP / IP Socket?

Damit kann ich leider nichts anfangen, tut mir leid. Dazu reichen meine Kenntnisse wohl nicht. Ich meine TCP/IP is klar, aber der Rest... ;)

Mfg xor
 
TE schrieb:
Ich habe Apache2, PHP und MySQL aus den src installiert[...]Ich habe nicht die möglichkeit den Paketmanager zu nutzen ;) Also fällt apt-get und die ganzen anderen Sachen weg ;)
...
 
Damit kann ich leider nichts anfangen, tut mir leid. Dazu reichen meine Kenntnisse wohl nicht. Ich meine TCP/IP is klar, aber der Rest... ;)

Dann hoffe ich mal, dass dieser Server nicht online verfügbar ist, sondern nur in einem Intranet benutzt wird... IPC steht für Interprozesskommunikation, also die Kommunikation von Prozessen untereinander. Unter Linux/Unix werden dafür zumeist procfs-Interfaces und Socket-Dateien verwendet. Der Standard-MySQL-Client nutzt automatisch den Zugriff via IPC, wenn auf localhost zugegriffen wird und TCP/IP, wenn der Zugriff remote stattfindet. Daher ist es wichtig, dass im client- und im mysqld-Abschnitt der my.cnf als Socket-Pfad die gleichen Werte stehen, wenn man lokal auf den Server zugreifen will.

@daboss: Es gibt gerade bei Server-Software genug Gründe auf die Version aus dem Paketmanagement zu verzichten. Setzt man z.B. verschiedene Distros in einer loadbalanced Umgebung ein, kann es notwendig sein auf allen Servern die gleichen Apache- und PHP-Versionen zu verwenden. Ausserdem kann man Updates zumeist selbst wesentlich schneller einspielen als es die Distros tun. Speziell bei MySQL kann es zu Situationen kommen, in denen man spezielle Storage-Engines benötigt, die man erst via Patch einbauen muss. Auch hier kann beim Einsatz verschiedener Distros der Einsatz gleicher Versionen notwendig werden, wenn man z.B. ein MySQL-Cluster oder eine Replikation aufbaut. Ich wage zwar zu bezweifeln, dass der TE solche Überlegungen angestellt hat, aber allgemein spricht bei Server-Software nur wenig dagegen das Paketmanagement zu übergehen.
 
@daboss: Es gibt gerade bei Server-Software genug Gründe auf die Version aus dem Paketmanagement zu verzichten. Setzt man z.B. verschiedene Distros in einer loadbalanced Umgebung ein, kann es notwendig sein auf allen Servern die gleichen Apache- und PHP-Versionen zu verwenden. Ausserdem kann man Updates zumeist selbst wesentlich schneller einspielen als es die Distros tun. Speziell bei MySQL kann es zu Situationen kommen, in denen man spezielle Storage-Engines benötigt, die man erst via Patch einbauen muss. Auch hier kann beim Einsatz verschiedener Distros der Einsatz gleicher Versionen notwendig werden, wenn man z.B. ein MySQL-Cluster oder eine Replikation aufbaut. Ich wage zwar zu bezweifeln, dass der TE solche Überlegungen angestellt hat, aber allgemein spricht bei Server-Software nur wenig dagegen das Paketmanagement zu übergehen.

Sorry, da kam meine Antwort falsch rüber. Das war als Antwort an meinen Vorposter gedacht, weil ich mir nicht vorstellen kann, das dpkg viel (aus)richten kann, wenn man Software selbst kompiliert hat ;)
 

Ähnliche Themen

Zugriff Ubuntu 16.04. auf Freigabe 18.04. LTS nicht möglich

Samba Dateien und Ordner verschieben

OpenJDK8 unter Debian7.11/sparc64/kernel 3.16 kompilieren

JBidWatcher: Problem bei loading Auctions in Verbindung mit mySQL

X startet nichtmehr

Zurück
Oben