nginx/1.6.2 bringt Fehler "504 Gateway Time-out"

Montaine

New Member
Hallo,

ich hab im Moment jetzt folgendes Problem..

Ich kann bei mir keine Datenbanksicherung mehr einspielen.

Mein Server läuft mit Debian 7.0 Wheezy Minimalsystem (64 Bit) mit PHP 5.6 und Nginx 1.6.2

Forensoftware: wbb 3.1.8 von Woltlab

Normalerweise habe ich bis jetzt Sicherungen über die direkte Administratorfläche vom Forum eingespielt, ist normal nicht notwendig. Durch den Ausstausch vom abgelaufenen SSL-Zertifikat ist es jetzt allerdings notwendig weil mir 2 Beiträge im Forum abhanden gekommen sind.

Also die Datenbank besteht bereits, es soll auf dieser lediglich die letzte Sicherung von gestern morgen mit eingespielt werden.

Jedenfalls, ein einspielen übers Forum funktioniert jetzt nicht, ich bekomm nach kurzer Zeit die Fehlermeldung

Gateway Time-out von nginx 1.6.2


Gut, so geht es nicht? Dann eben per Zugriff über die Shell.

Über Putty eingeloggt, im Terminal zu meinem backup-Ordner navigiert in dem die entsprechende sql-Datei liegt und folgenden Konsolenbefehl angewendet:

mysql -u root -p Datenbankname < sicherung.sql

Direkt danach kommt dann die Passworteingabe, mache ich per Strg +c, mit rechter Maustaste dann einfügen, denn es ist ziemlich lang und kryptisch. Das Ergebnis sieht jedoch immer so aus:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Gleiche Fehlermeldung erhalte ich wenn ich anstelle root den User 'forum' nehme so wie es in der config.inc.php hinterlegt ist.

Ich hab es ebenfalls über diesen Konsolenbefehl versucht:


mysql -uforum -pDEINKRYPTISCHESPASSWORT -hlocalhost forum < sicherung.sql

Nach diesem Befehl wirft es mich aus meinem backup-Ordner raus, ich lande direkt im Verzeichnis mysql und bekomme dazu dieses hier:

Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 926
Server version: 5.6.21-1~dotdeb.1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>


Ich bin mit meinem Latein ehrlich gesagt am Ende und fairerweise muss ich auch sagen das wir im Supportforum von meinem Hoster seit gestern bereits versuchen das Problem in den Griff zu bekommen. Eine Lösung ist jedoch nicht in Sicht und ich weiß im Moment nicht mehr was ich jetzt machen soll.

Das was bisher versucht wurde steht alles oben, vielleicht übersehe ich irgendetwas?

Vielleicht kommt ja jemand von Euch mit drauf wo das Problem liegen könnte.
 
Wie groß ist denn die .SQL-Datei?
Kannst du mal eine screen-Session erstellen, und nebenher mal schauen, wie sich die Ressourcen (RAM, CPU) während dem Import verhalten?

Ggf. wird auch etwas im Syslog dokumentiert.
Da mal reingeschaut?
 
Die .sql ist 57,4 MB groß, die liegt mir allerdings auch als sql.gz vor mit 15,1 MB.

Bis jetzt hab ich nur versucht die .sql einzuspielen denn die .gz müsst ich im Terminal ja auch erst entpacken und somit würd es auf das gleiche raus kommen?

Screen-Session.. wie mach ich das?

RAM und Cpu müsst ich über den Virtuozzo ja einsehen können... allerdings, wo genau find ich den Syslog?
 
So... ich hab jetzt noch was anderes raus gefunden, ich hab mich eben mal ans Telefon gehängt und mit dem Support telefoniert, da kam folgendes bei raus:

Da ich Debian als Betriebssystem habe funktioniert der vorige Befehl über die ganz normale Shell nicht. Ich muss dazu erst die Mysql-Shell starten und das mach ich so:

mysql -u root -p

root wird hierbei durch den Benutzernamen ersetzt der im Pfad /etc/mysql/debian.cnf steht. Dort ist ein Benutzernamen mit Passwort hinterlegt.

Laut Support sollte die Datei eigentlich 'passwd* heißen, die finde ich jedoch nicht.

Jedenfalls hab ich erstmal den Konsolenbefehl getestet und siehe da, mit dem Usernamen und dem Passwort kann ich mich tatsächlich in die mysql-Shell einloggen. Soweit so gut.

Da müsste nun eigentlich der vorherige Befehl:


mysql -u root -p forum < sicherung.sql

funktionieren, geht aber trotzdem noch nicht. Hab hier auch root durch den Usernamen ersetzt... oder muss ich hierfür nun doch einen anderen Konsolenbefehl nehmen weil es jetzt direkt im mysql-Shell ist?

Auch über die zusätzliche Pfadangabe /var/www/meineseite/wcf/acp/backup/sicherung.sql

geht es noch nicht.
 
Da ich Debian als Betriebssystem habe funktioniert der vorige Befehl über die ganz normale Shell nicht.
Das ist genau wie der Rest des Hinweises deines Supportes gelinde gesagt Quatsch. Zumal sollst du NICHT als debian-maint User in der Datenbank rumfummeln auch wenn er root-Rechte hat.

Der Befehl zum Einspielen einer Datenbank ist unter jedem 0815 Linux-System immer der Gleiche:
mysql -u BENUTZERNAME -p DATENBANK <DUMP.sql

Nach diesem Befehl wirft es mich aus meinem backup-Ordner raus, ich lande direkt im Verzeichnis mysql und bekomme dazu dieses hier:
Das ist nicht ein Ordner sondern ein Programm (Mysql CLI). Dies hat mit einer normalen Konsolenumgebung nichts gemeinsam.
Wenn dein Mysqlpasswort kryptische Sonderzeichen umfasst sollte es nicht mit "-pXXXX" eingegeben werden da die Sonderzeichen von der Linux Shell interpretiert werden und zu meist ungültigen Ergebnissen führt.

Gleiche Fehlermeldung erhalte ich wenn ich anstelle root den User 'forum' nehme so wie es in der config.inc.php hinterlegt ist.
Das klingt nach einem copy-paste Fehler wenn du sicher bist dass das die Kombination aus Benutzername und Passwort richtig ist.
Falls du mit "mysql -p" und dem root-passwort nicht verbinden kannst hast du entweder ein falsches Mysql Root Passwort (!NICHT! das Server-Rootpasswort) oder copy-paste Fehler.
 
Für diesen Befehl

mysql -u BENUTZERNAME -p DATENBANK <DUMP.sql

muss ich aber definitiv vorher im Terminal zu dem Pfad navigieren in dem die .sql-Datei dann liegt, richtig?

Dann ist nur noch die Frage.. ich hab einmal die Zugangsdaten für die DB in der config.inc.php hinterlegt, dort stehen Daten für Host = localhost, Datenbankname = forum, User = forum, Passwort: lang und kryptisch

und im Pfad /etc/mysql/ in der Datei debian.cnf den debian-maint User mit anderem Passwort.

Wenn ich Dich nun richtig verstehe muss ich die Zugangsdaten aus der config.inc.php nehmen, die akzeptiert jedoch genauso wenig wie den Zugang aus der debian.cnf-Datei.

Damit kann ich mich zwar auf der mysql-Shell einloggen, aber mehr macht er mir da nicht.

Ich krieg hier echt noch die Krise...
 
Das Passwort aus Deinem Script sollte eigentlich passen. Ich tippe auf Copy-Paste-Fehler bzw. Tippfehler bei langem Passwort. Wenn Du den mySQL-User root nimmst musst Du auch das entsprechende mySQL-RootPW nehmen. Mach es doch ganz klassisch auf der mySQL-Konsole:

Code:
mysql --user=Dein_ForumDB_User --password

> use db_name;
> source /pfad/zu/deinem/import.sql;
.
.
.
> quit;
 
Last edited by a moderator:
Uff.. ok.. ich habs jetzt mal so versucht nach der Eingabe kam dabei das hier raus:


Query OK, 0 rows affected (0,00 sec)

ERROR 1046 (3D000): No database selected
ERROR 1046 (3D000): No database selected
ERROR 1046 (3D000): No database selected
ERROR 1046 (3D000): No database selected
ERROR 1046 (3D000): No database selected

ERROR:
ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'INSERT INTO `wcf1_gmap_blog` VALUES (90,'.
Bye


Was ist das?
 
Back
Top