localconfig.php plötzlich leer....

[RaphaelOF]

Guten Morgen,

auch ich hatte nun bei zwei Projekten (2.11) eine komplett leere localconfig.
Jeweils auch All-inkl mit SMH.

[AgentK]

Guten Morgen,

auch ich hatte nun bei zwei Projekten (2.11) eine komplett leere localconfig.
Jeweils auch All-inkl mit SMH.

Hallo,

dann ist bei Dir der Job nicht korrekt ausgeführt worden, der die localconfig.php neu schreibt. Am besten aus deinem Backup die Datei nehmen und dann die leere einfach überschreiben.

Gruß
Stefan

[emkayy]

Das Problem besteht auch bei den neueren Contao-Versionen noch weiter.
Ich habe zwei 2.11.4 Installationen in denen der Fehler regelmäßig auftritt.
Der Inhalt der localconfig sieht dann so aus:

<?php

### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '/293.html';
### INSTALL SCRIPT STOP ###

?>

Bei einer Installation tritt der Fehler sogar mehrmals täglich auf!
Ich hab heute schon 3x die localconfig neu eingespielt.

Es kann doch nicht sein, dass so ein fehlerhaftes Script in die localconfig
schreibne darf! Wieso schreibt man das nicht ebenfalls in die cron.txt?

Da das ein absolut kritischer Fehler ist würde ich das Core-Team darum
bitten sich das nochmal anzusehen und mit in das nächste Bugfix-Release
aufzunehmen!

Bis dahin bleiben aber 2 Fragen für mich offen:

1. Wie kann ich die Fehlerquelle identifizieren?
2. Wie kann ich den Fehler ein für alle mal beheben?

Ich bin für jeglichen Tipp dankbar!

[Kahmoon]

Mir sind über Weihnachten auch 3 Projekte abgeraucht....Ursache unbekannt.....

Aber alles < 2.10

[manfred]

Von all-inkl. habe ich dazu heute folgende Support-email erhalten:

Dies ist leider ein altbewährter "Bug" von Contao.
Ich habe Ihnen die localconfig.php Datei, welche leer war, aus einem Backup vom 23.12.2012 wiederhergestellt.
Die Seite sollte nun wieder aufrufbar sein. Bitte prüfen Sie dies einmal.
Der Bug kommt leider hin und wieder bei Contao Seiten mal vor. Schuld sind im Grunde die Crons welche innerhalb des ContaoŽs laufen. Hierbei wird dann geprüft ob neue Versionen verfügbar sind oder es werden temporäre Dateien gelöscht.
Hier einmal ein Beispiel wie so was passieren kann:

Zwei quasi gleichzeitige Seitenaufrufe von verschiedenen Clients / Rechnern werden durchgeführt.
Der erste liest die Config Datei ein und führt den CronJob aus. Dann will Contao im Destructor der Config Klasse den neuen Inhalt mit dem geänderten Cron Timestamp (Zeitstempel) in die Datei speichern.
Während der Schreiboperation kommt nun der zweite Seitenaufruf und liest die noch unvollständig gespeicherte neue Config Datei ein. Da haben wir dann das genau das Problem.
Es empfiehlt sich also auch regelmäßig eine Sicherung der Datei vorzunehmen.

Vielleicht hilft das dem ein oder anderen weiter.
Gruß Manfred

[planepix]

Hallo Manfred, ich habs gleich nochmal auf Github ans Ticket angehängt:
https://github.com/contao/core/issue...mment-11714766

[gerritlo]

Ich habe das Problem auch immer mal wieder bei einer Seite. Komischerweise nur bei all-inkl.de obwohl nach deren Erklärung das Problem ja bei allen Providern auftauchen sollte.

Die Seite war auf 2.9. Ich habe nun ein Update auf 2.11.7 gemacht. Mal sehen, ob es wieder passiert.

Grüße

[xtra]

Ich habe das Problem auch immer mal wieder bei einer Seite. Komischerweise nur bei all-inkl.de obwohl nach deren Erklärung das Problem ja bei allen Providern auftauchen sollte.

Die Seite war auf 2.9. Ich habe nun ein Update auf 2.11.7 gemacht. Mal sehen, ob es wieder passiert.

Grüße

Prinzipiell hast du recht.
Potentiell tritt dieses als "Race collision" bekannte Problem yberall auf, jedoch ist es vom Faktor Zeit abhaengig.

Ich erlaeutere es dir nochmal ein wenig genauer.

Wir haben 2 Clients die beide die folgenden Aktionen durchfyhren:

• localconfig.php lesen
• Request bearbeiten und Ausgabe berechnen
• System deinitialisieren und localconfig.php schreiben

Das Problem tritt nun auf, sobald ein Client mitten in Schritt 3, also dem localconfig.php schreiben, ist und genau dann ein anderer client mit Schritt 1 anfaengt.

Nun kommen wir zu shared hosts, welche aus wirtschaftlichen Grynden meisst so voll gepackt werden wie moeglich. Dort bekommen also viel mehr threads eine Zeitscheibe, weil es einfach mehr Programmthreads gibt.
Daher ist es auch viel wahrscheinlicher, dass ein Prozess mitten in einem Schritt kurz unterbrochen wird und ein anderer Prozess die CPU fyr eine Zeit bekommt.

Wenn nur eine Webseite auf einem Server ist, dann bekommen nur die threads der clients dieser Seite eine Zeitscheibe, was beispielhaft dann mal 2 sind.

die wahrscheinlichkeit, dass nun genau diese 2 zu genau derselben Zeit genau dieses Problem heraufbeschwoeren indem eben der eine bei Schritt 1 und der andere bei Schritt 2 ist, ist derart gering, dass das Problem hier virtuell nicht existiert.

Wenn wir nun aber eine hochfrequentierte Seite und einen voll belasteten Server zugrunde legen, bei dem sagen wir mal 4800 gleichzeitige Zugriffe kommen, ist die Wahrscheinlichkeit, dass einer oder mehrere Prozesse gerade bei Schritt 1 oder 3 sind um ein vielfaches hoeher. Zumal man dann noch Betriebssystem abhaengige Gegebenheiten wie I/O wait (Zugriffszeit der Festplatte, Latenz des Netzwerks zu einem NAS, usw.), Prozessprioritaet und aehnliches eine Rolle spielen.

Je mehr traffic du auf deiner Seite hast, desto wahrscheinlicher sind solche Kollisionen.

In den aktuellen Contao Versionen wird die localconfig nur noch geschrieben, wenn selbige modifiziert wurde (seit 2.8.RC1), doch leider trifft das auch die cronjobs.

Somit sind diese auch im Fokus, da in Contao (<3.0) der cronjob nach jedem Durchlauf, seine last run time in der config abgelegt hat.
Daher hat sich der Fehler zwar seit 2.8 noch unwahrscheinlicher gemacht gehabt, aber erst seit 3.0 ist er eigentlich aus diesen Gruenden unmoeglich.

Eine recht sichere Abhilfe, in <3.0, ist eigentlich nur, die cron.php Aufrufe aus der fe_page gaenzlich zu entfernen und yber externen cronjob die cron.php direkt zu triggern (sonst werden die ja nicht mehr ausgefyhrt).

Gruss Chris

[Kahmoon]

Danke für die Info.

Dann heisst es jetzt mal Cronjobaufrufe ausbauen :-)

[BugBuster]

Bei der 2.11 sollte das nicht mehr passieren, da der Cron da gar nicht mehr in die localconfig schreibt.
Oder war das in der 3.0 erst so? Glaub ja. Hmm. Mist.

[sr-tag]

Ich hatte das Problem auch bei anderen Providern. Dort bin ich aber öfter zu dem Ergebnis gekommen, dass das Limit überschritten wurde.

Ich hab es mir dann so erklährt: Wenn die localconfig.php aufgerufen und neu geschrieben werden sollte wurde dies vom Webserver durch eine Speicherlpatzüberschreitung verhindert und er hat die Datei als 0 byte Datei liegen lassen. beim zweiten Aufruf kam dann logischerweise ein Fehler weil er ja die DB-Zugänge etc nicht mehr findet.

Nach einem Aufräumen des Servers/Mail-Ordners oder einen Anruf beim Hoster das Limit zu erhöhen konnte ich nach einer Weile die 0byte Datei durch ein Backup wieder überschreiben.

[phreak]

Hi alle,

Wollte hier auch nur mal zu den Akten geben, dass mir im letzten Jahr auch 3-4 Seiten abgeraucht sind, ebenfalls all-inkl.com. Teilweise sind dies auch Portale, die leiden bezüglich Google natürlich dann sehr unter solchen Fallouts. Werde auch mal investigieren, an den Speicherplatzlimits (Server) liegt es meines erachtens aber nicht.

Gruß

[Alexander]

Für die Akten:

Mir sind auch gleich mal ~10 Seiten bei all-inkl mehrfach hintereinander immer wieder abgeraucht. Unschön, wenn man nicht weiß, woran es liegt. Habe ungefähr dreißig mal geprüft, ob der Webspace voll ist ;-).

Viele Grüße
Alexander

[emkayy]

Also Speicherplatz hab ich nachgesehen - da is noch massig vorhanden!
Den Command Scheduler (pseudo Cron im HTML) hab ich im Backend deaktiviert und manuell einen Cron Job eingerichtet.

Trotzdem trat das Problem wieder auf! Lässt sich irgendwie verhindern, dass über den Cron Job in die Datei geschrieben wird? Evtl. über chmod?

Von mir aus auch im Core. Es geht einfach nicht, dass die Webseite ständig down ist.

An welcher Stelle schreibt denn der Cron in die localconfig.php?

[BugBuster]

Es wird auch bei anderen Aktionen in die localconfig geschrieben. Wenn du den CRON nun schon "ausgelagert" hast, dann kann es ja darüber nicht mehr zu konkurierenden Aufrufen kommen.
Sehr merkwürdig.

Wenn du den Cron nicht in die localconfig schreiben lässt, dann starten deine Jobs (stündlich,täglich,wöchentlich,monatlich) jedes Mal beim Start durch den echten Cron.

[BugBuster]

noch was emkayy.
lass doch mal den CRON für einen Monat ganz weg.
Wenn dann immer noch die localconfig zerstört wird, halte ich das nicht mehr für ein cron.php Problem, dann liegen die Ursachen ganz woanders, wo auch immer.
Es gibt auch Erweiterungen und wie gesagt Contao Backend selbst, was in die localconfig schreibt, nur nicht bei jedem Aufruf.

[dirksche]

Also ich hatte diese Probleme auch schon beobachtet. Ich trage nun immer in die .htaccess Datei

AddHandler php53-cgi .php

ein, und betreibe die Seiten nun ohne SMH.
Seitdem laufen die Seiten stabil.

[BugBuster]

Das ist immer der erste Weg, wenn nur irgend möglich, weg vom SMH, dann läuft die Seite auch etwas schneller.

[emkayy]

Hi, vielen Dank für euer schnelles Feedback!

Wie betreibe ich die Seite denn ohne SMH?

[BugBuster]

Welcher Provider?

[emkayy]

Hosting bei all-inkl.com

[BugBuster]

Dann lese mal hier die beiden Links

https://community.contao.org/de/show...l=1#post241678

Im ersten Link (Wiki Safemod_Hack) steht auch ein Beitrag drin wie es ohne geht bei all-inkl.
Im zweiten Link steht wie man per htaccess PHP im fast-cgi Modus bekommt.

[emkayy]

Danke! hab das AddHandler php-fastcgi .php eingebaut und auch die Besitzrechte nochmal auf den PHP-User geändert.

Gibt es jetzt eine Möglichkeit zu testen ob es wirklich ohne SMH und als fastcgi läuft? Bei all-inkl.com hab ich bisher nämlich immer nur von AddHandler php5-cgi .php gelesen aber noch nie von fastcgi. Ich möchte nur sicher gehen das auch wirklich alles so funktioniert wie geplant.

[xchs]

Du brauchst in Deiner ".htaccess" nur die Zeile zu ergänzen, die dirksche weiter oben bereits gepostet hat.

[d.tafel]

Hallo,

mir ist es grad auch passiert bei 2.11.4
Nur $GLOBALS['TL_CONFIG']['websitePath'] stand in der config

gibt es in neueren contao 2 ein fix in dem bereich (2.11.8)?

Grüße
Dennis

[Webkrebse]

Schade,
für den Kunden ist dieser Bug ein ziemliches KO-Kriterium für Contao. Jetzt gerade, wo es drauf an kommt, war seine Seite aus den geschilderten Gründen 2 x off.

Mal eine Frage am Rande:
Was macht der cron-Aufruf in der fe_page überhaupt?

EDIT: Habe hier was gefunden
https://community.contao.org/de/show...t-die-cron-php

Wenn ich das richtig verstehe ist der Aufruf in der fe_page also ziemlich überflüssig. Es reicht, wenn der Job - sagen wir einmal in der Woche - per echtem CRON aufgerufen wird.

[johndoe]

Hallo,

wir haben fast alle unsere Kundenwebseite bei All-Inkl. Wir hatten auch Wochen lang das Problem, dass Seiten plötzlich nicht mehr funktioniert haben, weil die localconfig.php auf einmal leer war. Allerdings hatten wir bei all diesen Webseiten den SMH aktiviert.

Wir haben dann bei all unserern Kundenwebseite bei All-Inkl den SMH rausgenommen und seitdem laufen die Webseite absolut problemlos.

-> KEIN SMH BEI ALL-INKL!

[do_while]

Es reicht, wenn der Job - sagen wir einmal in der Woche - per echtem CRON aufgerufen wird.

In Contao werden interne Bereinigungen und andere Aufgaben über diesen Cron erledigt. Ein Aufruf einmal die Woche ist sicherlich viel zu selten.
Der Cron steuert stündliche, tägliche und monatliche Aufrufe, in den neueren Releasess sogar minütliche, wobei das minimale Intervall 5 Minuten ist. Was der Cron in Contao alles steuert hängt sicherlich auch von den verwendeten Erweiterungen ab.

Wie man es haben will, muss jeder selbst wissen.

[neophron]

Hallo allerseits,

bei all-inkl liegt eine Contao 2.9.1 Installation wo die localconfig.php plötzlich leer ist.
Es existieren nur die db-Daten (db-name, db-passwort, db-user). Install Passwort ist nicht auffindbar.

Habe jetzt auf all-inkl eine Testinstallation mit 2.9.1 gemacht und die Inhalte der neuen localconfig.php rüberkopiert. Dort könnte ich die alten db Daten eintragen.

Wenn ich diese 2 Zeilen lösche

$GLOBALS['TL_CONFIG']['installPassword'] = 'bla bla';
$GLOBALS['TL_CONFIG']['encryptionKey'] = 'bla bla';

und mit »Contao« das Installations Passwort neu einrichte und die db aktualisiere, müsste doch theoretischerweise der Laden wieder laufen?

Oder soll ich erst nach der dem install Passwort die db Daten eintragen?

In der .htaccess würde ich noch

AddHandler php53-cgi .php

einfügen.

[neophron]

Ok, habe es eben getestet und die Seite läuft wieder.
Ich habe per ftp die localconfig angepasst und das wars. Da ich das Install-Tool nicht aufgerufen habe, musste ich auch kein Passwort einrichten.

backup, backup, backup