TL löscht eigene config

[Fryd]

OK, nicht immer, aber ich hatte jetzt folgenden Fall:

TL läuft in einem Verzeichnis mit Quota, d.h. mit beschränktem Speicherplatz (WebSpace). Durch unglückliche Umstände - auf die ich jetzt nicht weiter eingehen möchte - wurde dieser Speicherplatz zu etwa 105% belegt. Ich weiß nicht, ob das normal ist, das so etwas geht, aber es ist so passiert.

TL hat irgendwann nachdem das Überschreiten des Limits festgestellt wurde seine localconfig-Datei gelesen, sie anscheinend verändert und wollte die Datei wieder speichern, indem der Inhalt der localconfig gelöscht und die Datei dann neu geschrieben wird.

Das Löschen des Inhalts war kein Problem, aber wegen der überschrittenen Quota verweigerte der Server das Speichern der neuen Daten. Damit blieb die localconfig-Datei auf 0 Byte. Beim nächsten Lesezugriff auf die localconfig hatte TL dann überhaupt keine Idee mehr, was gerade läuft und gab nur noch eine Fehlerseite aus mit dem Hinweis, dass in der localconfig wohl eine Zeile fehlt.

Zum Glück hatte ich auf meinem PC noch eine ältere localconfig dieser Installation, so dass ich die Datei ersetzen konnte.

Meine Frage ist, ob TL von sich aus eine Sicherung der localconfig halten könnte, die auch unter diesen Umständen nicht verloren geht.

Grüße
Fryd.

[lindesbs]

Nein, da kannst du nichts machen. Es ist einbekanntes "Problem". Aber da muss leider auch der Admin mit aufpasssen. Wenn ich Aenderungen an Einstellungen mache, muessen die auch gespeichert werden.

Und wenn das Wasserglas schon voll ist, kannst du zwar was raus nehmen, aber dann noch mehr drauflegen geht nicht.

[andreas.schempp]

Gemein ist halt dass auch der Cron-Job oder andere Erweiterungen in die localconfig schreibt, und damit auch ohne eigene Änderungen etwas passieren kann. Im Prinzip steht nach der ersten Installation nicht mehr viel neues in der localconfig, also könntest du problemlos eine eigene Sicherheitskopie davon machen.

[xtg]

localconfig bis auf ein Fragment zerstört

Bei mir wurde die localconfig.php aus völlig unerfindlichen Gründen bis auf ein Fragment zerstört.
Das blieb übrig:

 
### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '/tl';
### INSTALL SCRIPT STOP ###
 
?>

Ich arbeitete mit TL 2.8.1 in zwei Fenstern an unkritischen Aufgaben (Artikel und News bearbeiten). Die Arbeit musste ich so lange unterbrechen, dass beide Fenster in den Session-TimeOut liefen (bei mir 60 Minuten). Dann stürzte FireFox ab und versuchte die Fenster zu rekonstruieren. Ergebnis: kein Zugriff mehr auf die Datenbank. Eine sofortige Prüfung brachte das oben gezeigte Fragment der localconfig.php zu Tage.

Der Webspace hat mehr als ausreichend Platz. Daran konnte es also nicht liegen...

Es wäre gut, wenn die Ursache geklärt werden könnte, da hier eine erhebliche Gefährdung der Zuverlässigkeit (und des Kundenvertrauens) vorliegt.

Vielleicht lassen sich die potentiellen Fehlerquellen ja noch weiter eingrenzen?

Beste Grüße aus Hannover
Thomas

[lindesbs]

Hast Du evt. irgendwelche Sonderzeichen im Passwort/DB Angaben usw. ?

[FloB]

… und keine abbrechenden Scripts sowie ausreichend memory_limit?

[xtg]

keine Sonderzeichen im Passwort/DB Angaben und üppig Memory, keine (erkennbaren) Probleme bei der Script-Ausführung!

[joker]

Bei mir wurde die localconfig.php aus völlig unerfindlichen Gründen bis auf ein Fragment zerstört.

Mir ist heute morgen dasselbe passiert.
Komischerweise wurde der weekly cronjob mehrmals gestartet und laut Log jedesmal komplett ausgeführt.
Komisch das ...

//Anmerkung Nina: Nur das Zitat gerichtet, damit es korrekt angezeigt wird.

[xtra]

So wie ich den code der cron.php aktuell beurteile, koennten wir da durchaus in race conditions geraten, wenn mehrere Seitenaufrufe "quasi simultan" ablaufen.
Das fyhrt dann dazu, dass cronjobs mehrfach durchlaufen werden.

Die localconfig.php sollte hierbei jedoch nicht wie von euch beschrieben zerstoert werden, da sie die ganze Zeit im Arbeitsspeicher liegt.

War das Fragment dasselbe?
Also ebenfalls nur der "websitePath" oder ein anderes setting?

Gruss
Chris

[joker]

War das Fragment dasselbe?
Also ebenfalls nur der "websitePath" oder ein anderes setting?

Sah so aus:

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

Hatte kurz davor In den Einstellungen die Ausgabe von Fehlermeldungen deaktiviert und die Zeitzone neu gesetzt. (aber sehe dazu keinen direkten Zusammenhang)
Nach dem daily- lief der weekly cron dreimal, dann erneut der daily (alle laut Log erfolgreich).

[acenes]

So wie ich den code der cron.php aktuell beurteile, koennten wir da durchaus in race conditions geraten, wenn mehrere Seitenaufrufe "quasi simultan" ablaufen.
Das fyhrt dann dazu, dass cronjobs mehrfach durchlaufen werden.

Die localconfig.php sollte hierbei jedoch nicht wie von euch beschrieben zerstoert werden, da sie die ganze Zeit im Arbeitsspeicher liegt.

Doch, das könnte zu diesem Effekt führen.

Beispiel:

2 quasi gleichzeitige Seitenaufrufe von verschiedenen Clients.

Der erste liest die Config Datei ein und führt den cron Job aus. Dann will sie im Destructor der Config Klasse den neuen Ihalt mit dem geänderten cron Timestamp 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.

Lösungsmöglichkeit:

Die Schreiboperation im Destructor der Config Klasse per Semaphore schützen.
Auf Dateibasis aber nicht universell lösbar weil Semaphore-Dateien (wie in Unix/Linux üblich) bei Windows nicht funktionieren. Ich selber habe bei meiner cron Erweiterung deshalb einen Lock in MySQL verwendet. Im Destruktor der Config Klasse könnte das etwa so aussehen:

do {
    $ql = $this->Database->prepare("select get_lock('configlock',0) as lockstate")->executeUncached();
} while (!$ql->next() || !intval($ql->lockstate));
$objFile = new File('system/config/localconfig.php');
$objFile->write($strFile);
$objFile->close();
$this->Database->prepare("select release_lock('configlock')")->executeUncached(); 

Zusätzlich wäre es natürlich sinnvoll auch den cron Job selber gegen doppelte Ausführung per Semaphore zu schützen.

[lindesbs]

do {
    $ql = $this->Database->prepare("select get_lock('configlock',0) as lockstate")->executeUncached(); 

Bei dieser Art des Lockings aber beachten, das dies alle DatenbankTypen ausser MySQL aussperrt. Das muss in den DB_Drivern geschehen, so wie das Locking der Tabellen, was Leo genutzt hatte. Siehe http://dev.contao.org/issues/2068

[acenes]

Richtig, ausserdem müsste man das Lesen mit dem gleichen Lock schützen, sonst hat man nur die halbe Lösung.

Besser wäre es wohl, die cron Timestamps in der DB zu speichern statt in der Config Datei.

[lindesbs]

Genau, und mit den Timestamps auch ein Locking. Zusaetzlich eine Kontrolle das die PHP Timeout nicht groesser als der Zeitabstand des Cron ist.

[SeDaFo]

Bei mir wurde die localconfig.php aus völlig unerfindlichen Gründen bis auf ein Fragment zerstört.
Das blieb übrig:

 
### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '/tl';
### INSTALL SCRIPT STOP ###
 
?>

Mir ist Heute zum 4. mal das gleiche passiert.
Hoster: Hosteurope
Multidomaininstallation Contao 2.9.1

Bisher lief alls ruhig, seit letzter Woche, wurde wie gesagt nun zum 4. mal die localconfig bis auf obiges Fragment gelöscht.
Kann es ein reines Hosteurope Problem sein?