Drupal - 1und1 Rootserver

Hallo,

check mal deine settings.php ob der Benutzername, Passwort und Datenbankname wirklich übereinstimmt.

mfg mofa

die Setings.php ist richtig und die Datenbank wird gefunden.
Sobald ich (zum Tesetn) z.B. einen falschen Benutzernamen eingebe, erhalte ich auch eine entsprechende Fehlermeldung.

So wie es aussieht, wird die Datenbank geöffnet und der Sql Server bricht anhand eines Fehlers ab.

Werde jetzt mal kpl. PHP und MySql neu installieren.

Gruß

Was sagt das Error-Log des Apache?

Php memory-limit?
Alles identisch, clean-url aktiviert oder nicht, stimmen die Dateisystemeinstellungen, werden module genutzt, die Schreibrechte benötigen....

Gruß Andreas

Mitunter hilft auch eine kleine Änderung in der .htaccess, ich glaube, ich hatte mit einem root-server ein ähnliches Problem

in diesem Abschnitt musste, glaube ich, RewriteBase / auskommentiert werden.

Gruß Andreas

Zunächst einmal sollte man ordentlich analysieren und nicht wie wild allemöglichen Sachen auf gut Glück machen.

So war das auch gemeint, ich wollte auch nur mehr Ansätze aufzeigen und hab dummerweise alles aufgeschrieben, was mir im ersten Moment so einfiel. Das mit der .htaccess hatte ich auch, auch bei 1und1, ist nur schon 'ne Weile her.

Ich würde auch mal, um mögliche Ursachen zu erfahren nach "white screen of death" hier, oder bei drupal.org suchen. Vllt gibt dir das auch ein paar Aufschlüsse woran es liegt, denn meiner Erfahrung nach kann es ganz verschiedene Ursachen haben. Hatte es selbst auch 2 Mal, und beides mal hatte es andere Gründe.

Wenn du Drupal "kopierst", sind dann irgendwelche Module aktiv, also zusätzliche Module? Vllt liegt es auch an einem davon.

Leudde, das schöne an Linux/Unix sind doch gerade die brauchbaren Fehlermeldungen und das Verzeichnis /var/log. Wenn der Server brüllt, dann in diese Tüte. Je nach Konfiguration (ich geh mal von Debian aus, in anderen Distros können die auch anders heißen) sollte /var/log/apache2/, /var/log/php5/, /var/log/messages/ oder /var/log/syslog weitere Informationen liefern.

--

Medienquelle • Agentur für Corporate Design, Kommunikation und Medien in Hamburg

Hallo,

Andreas:
die von dir genannten Einstellungen habe ich alle überprüft.
Cleen URL´s sind aktiviert, werden auch (lt. phpfinfo) unterstützt.
PHP Memory habe ich auf 120M gesetzt.

Genesis:
"white screen of death" habe ich schon hoch und runter gelesen und zum Teil ausprobiert. :)

Webseiter:
in der Apache log habe ich keine Einträge gefunden die mich weitergebracht hätten.
In der Mysql log sind Einträge vorhanden die einen Fehler bei einem SQL Dump ausgeben. Aber es ist jedes mal eine andere Tabelle die abgesprochen wird.
Wenn ich die DB von einem anderen Server aus aufrufe, meldet mir der Browser das es ein MySql Socket Problem ist.

So langsam verliere ich die Übersicht :)

Deshalb habe ich für Mittwoch einen Termin mit einem Linux-Fachmann gemacht, und ich hoffe dass wir das Problem lösen können indem er mir auf den Server genau die gleiche Konfiguration (AMP) installiert wie ich sie auf dem lokalen Server habe.

Werde dann auf jeden Fall berichten, wass die Ursache war (oder hier nach jemandem suchen, der mir den Server einstellen kann)

Gruß
Zdenko

Mich würde das wirklich mal interessieren... Berichte bitte, woran es nun gelegen haben wird.

Nochmal möchte ich Dir die .htaccess ans Herz legen. Der Standard Root-server wird, wenn ich mich recht entsinne, mit Plesk administriert, dieses nimmt auch alle Einstellungen des Servers vor. In dem Fall hast Du kein "echtes" sondern ein "virtuelles" Document-Root Verzeichnis. Folgender Thread hat mich überhaupt erst bewogen in der .htacchess zu suchen, auch wenn es da nicht direkt um nen Root-Server geht.
http://www.drupalcenter.de/node/7145

Viele Grüße

Andreas

als kleiner Tipp ! mir ist aufgefallen das Mysql 5.0.45 bei der instalation von Drupal 6.9 die instalationsrutine zum erzeugen von Tabellen teilweise falsch interpretiert - dabei werden in bestimmen Tabellen falsche typen gesetzt welches bei der ausführung von anfragen zu einem resart des sql servers führt.

Danach hast du den WSOD den du nur durch löschen der in die tabellen geschriebenen Inhalte (per PhpmyAdmin) wieder lösen kannst.

evt. hilft dir das weiter - ansonsten würde mich interessieren wo das problem lag.

Gruss menschwagner

Den Tipp mit der htaccess würde ich auch als relativ heiss werten.

Zwar weiss ich nicht, wie es sich bei Root-Servern dieses Anbieters verhält, jedoch nehme ich fast an, dass deren Config stark dem Standard gleicht.

Versuche doch mal, die ersten Zeilen bis
"# Set the default handler.
DirectoryIndex index.php"

auszukommentieren.

Nach ein paar Anpassungen an der PHP Konfiguration konnten wir folgenden Fehlerverlauf nachvollziehen:

Drupal baut eine Verbindung mit dem mysql Server auf und dieser steigt dann aus. Er startet zwar gleich sofort wieder, aber es kommt nur eine mysql Fehlermeldung das der Server die Verbindung unterbrochen hat oder (seltener) meldet PHP das die Verbindung über den mysql socket nicht aufgebaut werden konnte (was ja auch logisch ist, wenn der Server gestoppt ist).

Ein Versuch den Mysql Server (über Yast) neu zu installieren hat Yast zerschossen.

Jetzt haben wir den Server neu initialisiert und zwar in der Minimalkonfiguration (ohne Plesk).
Leider kann es lt. 1&1 "eine bis mehrere Stunden" dauern bis der Server wieder erreichbar ist.

menschwagner:
das irre an der Sache ist ja gerade die Tatsache, dass eine Neuinstallation ohne probleme gemacht wird !
Und wenn ich alle Module aktiviere die auch auf dem lokalen Entwicklungsserver laufen läuft immer noch alles.
Aber sobald ich die Tabellen hinzufüge (Inhalte, Inhaltstypen etc.) steigt der mysql Server aus.
Aber auf dem Entwicklungsserver (mit der fast gleichen Konfiguration) laufen die Seiten tadellos.

Der einzige, wirkliche Unterschied zwischen den Servern (lokal und 1&1) ist Plesk.
Und ich vermute mal, das es ein Konfigurationsproblem von Plesk ist, das den Smysql Server so unstabil reagieren läßt.

Eben habe ich eine Mail von 1&1 erhalten, dass der server wieder online ist.

Jetzt muß ich aber erst die Domains konfigurieren und alles andere einrichten bevor ich Drupal wieder aufspielen und weiter testen kann.

Ich werde euch auf jeden Fall auf dem Laufenden halten.

Gruß
Zdenko

Ist eine Weile her, dass ich zuletzt Plesk irgendwo laufen hatte / installiert habe. Aber für gewöhnlich machen die diversen Admin-Panels keine Extrawürste für die DB-Konfig. Kann mich jedenfalls nicht entsinnen, dass irgendwann mal irgendein Tool eine eigene Konfigdatei für MySQL gehabt hätte. Von daher würde ich deine Vermutung mal unter Vorbehalt hinten anstellen.

MySQL schmeißt sich im laufenden Betrieb im Grunde auch nur im Falle von Softwarefehlern / Hardwarefehlern und dergleichen weg. Bei solchen Standardanforderungen wie hier aber kann man einen MySQL-Softwarefehler quasi ausschließen (ihr habt ja sicher nicht irgendwelche MySQL Beta Versionen mit eigenen Patches oder dergleichen laufen).

Es könnte, ganz vorsichtig gesprochen, ein defekter RAM Baustein sein (dann schmiert i.d.R. aber dann und wann auch mal was anderes ab), ein defektes Board (praktisch nicht direkt diagnostizierbar) und ein Fehler im Dateisystem / auf der Platte.

Habt ihr noch nen andere Mühle oder Webspace + DB online, die ihr testen könnt?

Wie stehts bei euch mit Monitoring? Von Hand oder mit z.B. Munin? Was sagen die SMART Werte der Platte(n)?

Habt ihr nen RAID Controller drin? Firmware-Udate? Treiber im Kernel?

welche fehler meldung steht den im error log - in plesk kannst du das unter dem menuepunkt server einsehen.

wenn die berechtigungen falsch gesetzt werden ( unique anstelle von index) funktioniert die instlation der module einwandfrei - erst wenn du die tabellen mit inhalten füllst steigt der server aus.

zu htaccess

kann mit absoluter sicherheit sagen das das problem dort nicht zu suchen ist - betreibe unter anderem auch eine Rootserver bei 1und1 (L64) und dort funktioniert die htaccess einwandfrei ohne aenderung.

Mal ganz blöd gefragt:

Wie importierst Du die alten Datenbanken.

Wahrscheinlich doch über die PHPmyadmin Importfunktion?

Bei Strato habe ich die Erfahrung gemacht, dass deren SQL Server ab und zu mal streikt, wenn es darum geht die Ânweisungen wie die folgenden:
"
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
"
zu verarbeiten
in diesem Fall wurden die Anweisungen bis zum ersten
"CREATE TABLE IF.."
entfernt.
Ausserdem störte sich der Import an
"...ENGINE=MyISAM DEFAULT CHARSET=utf8"

Evt hilfts ja weiter...

---

Folgendes zum ausprobieren:
1) Was passiert, wenn die 1&1 Drupal Dateien auf einen externen (zu Hause) Server zugreifen (ausser, dass es saulangsam ist)
2) Was passiert, wenn ein "Zu Hause" Drupal Core auf den 1&1 Server zugreift?
3) Was passiert, bei einem "Select *" auf alle Tabellen (In PHP Myadmin?)

Hallo an alle,

letzte Nacht habe ich noch einen weiteren Versuch gestartet und den Server neu initiatilisiert (wieder mit Plesk im Paket).
Aber diesmal nicht die von 1&1 verwendete Voreinstellung mit dem 64Bit System sondern mit dem 32Bit System.

Und Drupal läuft nach ein paar Standard-Konfigurationsanpassugen ohne zu murren.

Eigentlich hätte ich schon eher drauf kommen müssen, aber da das System ja schon vorinstalliert war und Dupal nach einer kpl. Neuinstallation ja auch ordentlich gelaufen ist, habe ich gar nicht im 1&1 Controllcenter nachgesehen (und nur dort steht der Hinweis auf die Voreingestellte Version von Linux.

Der Konflikt scheint also nicht im Zusammenspiel mit den Drupal Core Modulen aufzutreten, sondern mit einem der nachinstallierten Module sobald er auf bestimmte Datenbestände zugreift.

menschwagner
welche Linuxdistribution läuft auf deinem L64 Rootserver (32 oder 64 Bit) ?

passer
ich importiere die daten immer direkt als sql dump über das sql-befehlsfenster bei phpMyAdmin.

Die Probleme die Du beschreibst, treten oft auch bei anderen Hostern auf. Liegt aber (glaube ich zumindest) an der performance des sql Servers.

@zdenko Auf dem 1und1 Rootserver läuft opensuse10.3 64bit

Nutzt du das Core modul Path ?? damit hatte ich unter der Sql version 5.0.45 probleme

@menschwagner

Ja das Path Modul benutze ich.
Aber jetzt benutze ich es auch und es funktioniert bis jetzt ohne Probleme.

Aber ich werde die Installation jetzt übers Wochenende mal detailiert Testen.

Gruß
Zdenko

path modul verursacht probleme unter Mysql 5.0.45 aber erst wenn du mehr als einen Alias eingibst dann reist die verbindung zu Datenbank ab un du bekommst den WSOD.

Wenn du eine frische instalation aufgespielt hast und das modul instaliert ist versuch mal mehr als einen Alias anzulegen - wenn du dan den WSOD bekommst kann ich dir sagen woran es liegt

Gruss menschwagner

@menschwagner

Das könnte auch bei mir die Ursache des Fehlers gewesen sein.

... wollte eben mal eine neue Installation machen, aber das macht ja keinen Sinn da ich ja jetzt die 32Bit Version auf dem Server habe :-)

Aber ich ich gehe mal davon aus, dass ich den WSOD wieder bekommen hätte.

Kannst mir ja dennoch verraten woran es genau gelegen hätte ;-)

Gruß
Zdenko