TL löscht eigene config

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.

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.

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.

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

Code:

---


### 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

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

… und keine abbrechenden Scripts sowie ausreichend memory_limit?

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

Zitat:

---

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. :rolleyes:
Komisch das ...

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

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

Zitat:

---

Zitat von xtra

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

---

Sah so aus:

Code:

---

### 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).

Zitat:

---

Zitat von 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.

---

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:

PHP-Code:

---

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.

Zitat:

---

Zitat von acenes

PHP-Code:

---

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

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.

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

Zitat:

---

Zitat von xtg

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

Code:

---


### 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?

Nein. Hatte das auch schonmal woanders (tng.net, VServer).

Bei uns ist das Problem zwei Mal aufgetaucht. Ein Mal auf einem localen Testserver und ein Mal auf einem Server bei SPeedbone (Prosite). - Seither allerdings (Toi,Toi,Toi) nicht mehr. - Vieles spricht dafür, dass tatsächlich die Timeout-Situation die Fehlerquelle war. Lässt sich nur leider nicht rekonstruieren/provozieren.

Hat dazu schon einer ein Ticket mit der genannten Lösung gemacht? :)

Zitat:

---

Zitat von Nina

Hat dazu schon einer ein Ticket mit der genannten Lösung gemacht? :)

---

Ich konnte diesbezüglich im Ticketsystem (noch) nichts dergleichen finden.

Wenn es wirklich die cron.php ist , dann raus damit aus dem fe_page.tpl und das Teil per echten Cron aufrufen, sofern man dies auf seinem Server zur freien Verfügung hat.

Solange bis es eine offizielle Lösung gibt wie hier schon angedeutet.

Wäre das was für die DevCon als Thema?

Zitat:

---

Zitat von BugBuster

Wäre das was für die DevCon als Thema?

---

Unbedingt! So viele wie damit schon ihre Probleme hatten...

Ich hab das jetzt mal als etwas "roh formuliertes" Ticket gepostet. Mal schauen was Leo dazu meint.

Der Aufruf der cron.php steht ja als normaler img-Link im Quelltext jeder Seite. Kann der Link durch hochfrequenten Mehrfachaufruf bewusst dazu eingesetzt werden, Contaoinstallationen platt zu machen?

Wenn ja, sollte cron.php dann durch eine leere Datei ersetzt und die Originaldatei umbenannt werden?

Fryd.

Könnte man denn nicht die localconfig einfach exklusiv öffnen?
Ich bin jetzt nicht wirklich fit in Unix-Dateisystemen, aber man müsste doch da auch ein Locking drauf setzen können, oder?

Hier mal ein Link, in dem das beschrieben wird:
http://selfhtml.bitworks.de/artikel_...el/artikel.htm
http://php.net/manual/de/function.flock.php

Hallo,

gestern Abend ist es wieder passiert. die localconfig ist nicht korrekt geschrieben worden. Diesmal aber etwas merkwürdig:

Zitat:

---

....bis hierher i.O., dann:

$GLOBALS['TL_CONFIG']['maxResultsPerPage'] = 100;
$GLOBALS['TL_C =
### INSTALL SCRIPT STOP ###

?>

---

Diemal habe ich weniger hektisch reagiert, die defekt lococonfig behalten und angefangen die Logfiles von Hosteurope für diesen Zeitraum durchzuforsten. Dabei ist mir aufgefallen, daß von der selben IP-Adresse eine bestimmte Domain im 3 Sekunden-Takt aufgerufen wurde (ich habe eine Multidomain-Installation) insgesammt 1037 mal, wohlgemerkt nicht die Seite angeschaut (gesurft), sondern nur die Domain aufgerufen. Unterbrochen nur durch andere Surfer, bemerkbar nur dadurch, daß als er Zeitweise "allein" auf der Seite war eben nur seine IP angezeigt wurde und sonst nichts
(IP.IP.IP.IP.IP- - [19/Oct/2010:11:58:48 +0200] "GET /cron.php HTTP/1.1" 501 335 "http://www.domain.de/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10" "www.domain.de")
Ich habe erstmal die cron.php aus dem Template entfernt...

Werde die Sache weiter beobachten...

Kontrolliere mal bitte deine max_execution_time in der php Konfig.

3 Sekunden Takt ist nu nicht der Wahnsinn, klassische Scanner, oder jemand aus der Region Stuttgart der dich aergern will.

Du koenntest evt. mal versuchen, das auf die cron.php nur von lokal aus aufgerufen wird.
also via htaccess

Hallo lindesbs,

danke für die schnelle Antwort. Die max_execution_time ist auf 30, soweit ok.
Ich werde die cron.php durch einen eigenen Cronjob ausserhalb von contao aufrufen, ist für mich einfacher ;-)

Hat man da evtl. versucht, wie von acenes hier beschrieben, einen simultanen Aufruf des cronjobs zu erzwingen?

OK, bei einer execution Time von 30Sekunden und alle drei Sekunden wird dein cron getriggert, koennen theoretisch bis zu 10 Instanzen parallel laufen.

Das ist ein konzeptionelles Problem, da hier nicht mit Locking oder Semaphoren gearbeitet wird.

Ich suche mal durch den Bugtracker. Wenn ich nichts finde, werd ich ein neues Ticket erstellen, mit einem Loesungvorschlag.

Im Bugtracker hier zu finden.


Da ich keinen Cron Job auf meinem Hoster habe, werde ich bei mir den Cron Aufruf rausnehmen aus der fe_page und für die Impressumseite mit einem extra fe Template diesen nur dort aufrufen. Die wird nur sehr selten aufgerufen.
Da ich selber aber auch einmal die Woch raufschaue, kann ich ja dann selber den cron auslösen damit :cool:

Aber eine Lösung die auf allen Betriebssystemen / Datenbanken funktioniert, sollte schnell erfolgen.

inhalt der localconfig:

Code:

---

### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '';
### INSTALL SCRIPT STOP ###

---

?>

Ein paar Angaben:
Webspace ist noch genügend Platz
Kein SMH
Contao cron und Scheduler-Erweiterung
Das Dateidatum der kaputten localconfig ist 7.11.2010 12:14. Der letzte Eintrag der access.log ist aber mit 00:04:00 protokolliert, also viel früher.

Gruß
ChrMue

error.log? (Apache + Contao)

in der Error-log steht nichts außergewöhnliches d.h. nur die Einträge, die sonst auch immer mal wieder auftauchen.
Auch finde ich im Backend unter System - System-log nichts besonderes

Irgendein Query muss ja durchgekommen sein, evtl. mit einem 500er-Fehler (z. B. PHP-Fehler out-of-time, out-of-memory). Oder hast du einen richtigen Cronjob eingesetzt?