Update 3.5.4 - check.php & alles top, „Speichern” und der Server geht 30min offline

[leone]

Zunächst:
Hab eine frühere 3.1.1 auf dem lokalen MAMP per Live-Update auf 3.5.4 aktualisiert. Lokal einfach deshalb um noch testen zu können. Alles funktioniert dort bestens. Nach Upload auf den Webserver (samt DB natürlich) per install-tool ohne Probleme wieder eingerichtet - alles einwandfrei, die Website wird prima ausgeliefert, alle Erweiterungen laufen, Backend-Anmeldung geht wie gewohnt, check.php (auch angewendet auf die Installation) zeigt alles aktuell und keine Probleme.

Aber:
Egal welcher Bearbeitungs- bzw. Speichervorgang, also z.B. ein Textelement ändern oder (wie natürlich gleich zuerst passiert) „Daten bereinigen” unter Systemwartung schickt den Server 30min offline und es wird dann auch nicht gespeichert - klar.

Leider kann ich nicht sehen was tatsächlich passiert, denn ich hab keinen Zugriff auf die Fehlerprotokolle. Hat jemand einen Tipp woran das liegen kann? Was für ein Problem könnte beim Schreiben bzw. Versuch zu schreiben in die DB so gravierend sein nachdem zunächst „alles auf grün” steht?
Ich dachte es wäre ein Vertipper im Feld Port (für die MYSQL), denn ich hatte da mal versehentlich 3336 statt 3306 eingetragen. Aber auch nach Korrektur kommt's zum gleichen "Dienste-crash" und Neustart nach 30min. Die frühere 3.1.1 - Installation läuft an gleicher Stelle platziert (und mit der eigenen db natürlich) ohne jede Einschränkung.

Vielen Dank im Voraus für jeden Tipp!

PHP 5.5.9 auf Ubuntu 4.13, beide Installationen ohne safe-mode hack

[Kahmoon]

Schlechter Hoster?

Sowas höre ich das erste Mal.

Edit:
3.1.1 lief da schon? hmm dann weiß ich auch nicht..sorry

[tab]

Der Check liegt auch wirklich im Installationsverzeichnis bzw eine phpinfo im Installationsverzeichnis bringt das selbe Ergebnis wie die hier verlinkte?
Mal abgesehen von den Problemen. Der Check prüft die Datenbankverbindung nicht, der kann also fröhlich alles grün anzeigen auch ohne funktionierende Datenbankverbindung. Wenn das Installtool allerdings sagt, dass die Datenbank up to date ist, dann sollte doch wohl eine Verbindung bestehen. In der Datei system/logs/error.log steht auch nichts passendes drin? Da würd ich jedenfalls mal reinschauen.

[tab]

Hmm, es gab da schon mal einen Fall, wo eine Datenbank einfach nicht richtig funktioniert hat bei einem Hoster, während andere DBs bei dem Hoster problemlos liefen. Damals hat der Hoster das dann wohl "repariert". Sieht ja bei dir eigentlich so aus, als ob Abfragen (reine Lesezugriffe) möglich sind, es aber mit dem Schreiben hapert. Damit könnte das Installtool die vorhandenen Tabellenstruktur ohne Probleme prüfen. Vielleicht sind auch nur einzelne Tabellen betroffen, denn sonst sollte auch ein Login schon Probleme machen, weil in die tl_session nicht geschrieben werden kann (und auch nicht in tl_log). Eventuell mal die Tabellen reparieren, vielleicht sagt ja aber auch die error.log schon was zum Problem.

[leone]

Vielen Dank für die schnellen Antworten!

tab's Hinweis aufs log bringt mich glaub ich weiter:
[21-Oct-2015 19:59:50 GMT] PHP Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'root'@'localhost' (using password: YES) in /var/www/vhosts/XXX.de/httpdocs/system/modules/core/library/Contao/Database/Mysqli.php on line 46
und
[21-Oct-2015 20:00:08 GMT] PHP Fatal error: Uncaught exception 'Exception' with message 'Access denied for user 'root'@'localhost' (using password: YES)' thrown in /var/www/vhosts/XXX.de/httpdocs/system/modules/core/library/Contao/Database/Mysqli.php on line 50

Demnach wird mit den Einstellungen der lokalen Installation (unter MAMP) versucht zuzugreifen, obwohl das Installtool mir mit den korrekten DB Einstellungen des Webservers einen Zugriff ohne Beanstandungen bestätigt. Hier werd ich jetzt aber weitersuchen.

@Kahmoon: Es könnte auch am Hoster (der sich schon mal über contao bei mir beschwerte) des Kunden liegen. Auf unserem Server ist mir das auch noch nie passiert. Aber ich glaube wie tab es schreibt sollte ich erst mal die Tabellen und Einstellungen prüfen um sicher zu sein, dass überhaupt korrekt auf die DB zugegriffen wird, bzw. versucht wird korrekt zuzugreifen.

[tab]

Einfach mal in die system/config/localconfig.php reinschauen. Da hätte eigentlich das Installtool die eingegebenen Datenbankzugangsdaten reinschreiben müssen. Dort liest sie auch Contao, wenn also z.B., aus welchem Grund auch immer, deine Daten dort nicht eingetragen werden konnten (Schreibrechte?), dann würde das erklären, wieso von Contao die alten Daten von deinem lokalen System benutzt werden. Und auch, falls das Installtool die Daten nach dem Schreiben nicht extra wieder frisch einliest, wieso das Installtool durch die Datenbankprüfung durchlaufen konnte - es hätte ja die korrekten, von dir eingegebenen Daten benutzt.

[leone]

Ich fürchte die Einträge im log stammen vom ersten Aufruf des install-tools vor den korrekten Eintragungen dort, denn in der local-config stehen die richtigen Einträge für den Zugriff auf die DB auf dem Webserver. Leider kann ich das ganze nicht so oft testen, bzw. nur spät am Abend, weil der Server dann tatsächlich für 30 min streikt. Ich werde die Installation jetzt mal auf unserem eigenen Webserver testen. Ich hab mich auch schon gefragt ob es ein Webspace bzw. Datenbankgrößenproblem sein könnte, aber die andere 3.1.1 Installation tuts ja.
Die Daten in der localconifg sind identisch mit Ausnahme von Benutzer und Passwort für die DB...

[leone]

Endlich gelöst wenn auch nicht abschließend zu erklären:

Ich habe wegen des Dienste-Crashs immer nur spät am Tage verschiedene Installationen/Updates getestet also z.B. auch von 3.1.1 (der noch problemlosen Ausgangsinstallation) auf 3.2.7 und auch auf 3.5.4 immer mit dem Ergebnis, dass der Server bei ganz normalen Backend-Aktionen also einfachem „Speichern” von geänderten Textelementen etc. für 30min nicht mehr aufrufbar war.

Im Wartungsmodus passierte das jedoch nicht und so konnte ich per Hinterlegen eines .skip-files (wie hier im Forum beschrieben - thanks again) die Erweiterung ermitteln, die das Problem verursacht. Der Slider "dk_caroufredsel" muss trotz Aktualisierung irgendeinen Schaden genommen haben. Ohne ihn lief alles. Durch Löschen (Files und Tabellen) und Neuinstallation dieser Erweiterung läuft nun alles wie gewohnt und gewünscht und auf letztem Stand 3.5.4