localconfig.php plötzlich leer....

[timbugto]

Hallo,

Ich stellte heute früh mit erschrecken fest das unsere Company Project Website nicht mehr abrufbar war.
Es kam die gelbe Error Box: - error log checken und in localconfig die Fehlermeldung anschalten...

Im ErrorLog stand nix drin, aber dann sah ich das die localconfig.php komplett leer war - nix drin. Wie kann das sein? Gestern Abend ging noch alles, hatte seit dem an der Seite nix mehr gemacht...

Ich habe nun eine localconfig.php copy auf den Server geladen und läuft wieder alles. Es war jetzt das erste mal, aber wie kann so etwas passieren - und hoffentlich nicht noch einmal?

[Toflar]

Jemand der FTP access hat oder eine Extension, die die localconfig.php löscht (warum auch immer^^)
Contao löscht seine Einstellungen auf jeden Fall nicht einfach so selbst

[timbugto]

ftp access habe nur ich und eine extensions? ist ja die ganze zeit nix passiert, nur gestern nacht... gibt es vielleicht eine andere möglichkeit?

[lucina]

Naja, das kann schon aus mehreren Gründen passieren, die alle nicht so nett sind:

Zum Beispiel kann der Webspace schlicht voll sein (zum Beispiel durch Logfiles), und wenn Du dann die Systemeinstellungen aufrufst und erneut speicherst, dann kann die localconfig.php ggf. nicht mehr geschrieben werden.

Eine andere Möglichkeit ist eine Extension, die Settings in der localconfig.php ablegt - entweder wie oben durch Speicherplatzmangel, oder (und das ist auch nicht nett) in Form von formatiertem Text, wodurch es dann auch möglich ist, die Datei total zu schreddern (mit der Eingabe von $, §, einkopierten Word-Texten, etc).

Ich kenne aktuell eine Extension, die das so macht, habe bereits auf das Problem hingewiesen, aber bisher kein brauchbares Feedback erhalten.

Schau doch mal, ob Du damit was anfangen kannst.

[timbugto]

Ich denke das kann eigentlich nur vom Speicherproblem her sein...

Also ich habe eben eine Email an den Web Hoster geschickt, ich habe keine Ahnung wieviel Speicher noch frei ist. Kann ich das selber irgendwo nachschauen?

[Toflar]

Das hängt vom Hoster ab, aber den verfügbaren Space solltest Du eigentlich schon einsehen können. Ansonsten würde ich mir schon einige Fragen stellen

[HSec]

Wir haben das Problem ebenfalls festgestellt, haupsächlich bei Projekten, die bei all-inkl gehostet sind.
Es tritt seit Version 2.9 ein Mal pro Monat auf, allerdings nicht alle 4 Wochen, und auch nicht bei allen gleichzeitig.
Bei einem der Projekte trat das Problem heute erneut auf, zuletzt in der ersten Augustwoche und davor am 22. Juli 2010. Die ersten Male während der Nacht gegen 2 Uhr, heute kurz nach 11 Uhr.

Ursachen sind und waren weder der Webspace noch Erweiterungen, da zum einen nur ein Projekt eine Erweiterung installiert hat und zum anderen reichliche Webspace vorhanden ist.

Nach mehreren (und stundenlangen) Gesprächen (Fehler- und Ursachensuche) mit all-inkl kamen wir zu keinem auswertbaren Ergebnis, nur, dass die Ursache mit den Crons im Zusammenhang stehen könnte.

Eintrag: [11.09.2010 - 05:13:11] No active page for page ID ......

Danach keine Aktivitäten.

Der nächste Eintrag:

[11.09.2010 - 11:21:41] Running daily cron jobs
...
[11.09.2010 - 11:22:16] Running weekly cron jobs
[11.09.2010 - 11:21:55] Daily cron jobs complete
....
[11.09.2010 - 11:22:36] Running weekly cron jobs
[11.09.2010 - 11:22:17] Weekly cron jobs complete
....
[11.09.2010 - 11:22:41] Running weekly cron jobs
[11.09.2010 - 11:22:37] Weekly cron jobs complete

usw.

Gruss

HSec

[do_while]

Hallo HSec,

willkommen in der Contao-Community!

Einen monatlichen Cron-Aufruf gibt es bei Contao nicht, Du müßtest also versuchen einen Zusammenhang mit dem stündlichen, täglichen oder wöchentlichen Cron-Aufruf zu finden.
Welche Aktivitäten alle für den Cron registriert sind, findest Du, indem Du alle Quelldateien Deiner Installation nach folgenden drei Variablen durchsuchst:

$GLOBALS['TL_CONFIG']['cron_weekly']
$GLOBALS['TL_CONFIG']['cron_daily']
$GLOBALS['TL_CONFIG']['cron_hourly']

Für monatliche Ereignisse müßte der Aufruf dann von außen kommen.

[HSec]

Hallo, do_while,

danke für deine Antwort.

Ist sagte nicht, dass es einen monatlichen Cron gibt, sondern, dass die localconfig monatlich geleert wird - aus welchem Grund auch immer. Anscheinend willkürlich, da an irgendeinem Tag und zu irgendeiner Uhrzeit, aber eben ein Mal pro Monat.

Und dies könnte mit den täglichen oder wöchentlichen Crons im Zusammenhang stehen.

Tatsache ist, dass es in den Logs (auch den Server-Logs) keinerlei Hinweise gibt und aus irgendeinem Grund die localconfig plötzlich leere ist, obwohl es unmittelbar davor (vor einem Cron) keine Ereignisse gab, die Crons somit (aufgrund leerer localconfig) bis zur Behebung des Problems ins leere laufen.

Es gibt keinerlei Hinweise auf Ereignisse von außen, auch in den Server-Logs nicht.

[do_while]

Ich betreibe selbst einige Contaos auf All-Inkl Webspace, dort gibt es diese Probleme bisher nicht.

Contao 2.9.1
all-inkl PrivatPlus

[HSec]

Auffällig ist, dass es bei allen Projekten auftritt, die 2010 zu all-inkl wechselten. Alle benutzen PrivatPlus. Und es läuft Contao 2.9.1.

all-inkl beteuert (jedes Mal), dass es nicht am Server liege, und auch kein Neustart etc. durchgeführt wurde oder andere Ereignisse eingetreten seien, durch welche Probleme hervorgerufen werden könnten.

Und, wie erwähnt, hat nur ein Projekt eine Erweiterung (MultiTextWizard 1.1.0 stable) installiert.

Bei Projekten, die wir vor 2010 einrichteten, tritt das Problem (bisher) nicht auf - nunmehr ebenfalls alle Contao 2.9.1.

Wir haben nun fast drei Monate nach der Ursache gesucht und glaubten, alles getan zu haben, dass das Problem nicht mehr auftritt.

Nun, am heutigen Tag erneut.

Momentan haben wir bei diesem sonderbaren Ereignis keinen Plan mehr.

[do_while]

Hallo HSec,

arbeitet Ihr bei den Domains mit dem SafemodeHack oder mit dem CGI-Modul?
http://www.contao-community.de/showt...dien-M%FCnnich

[HSec]

Ja, bei allen mit Safe Mode Hack.

Daran hatten wir auch schon gedacht, konnten aber nichts finden, was einen Zusammenhang herstellen könnte.

Ohne Safe Mode Hack haben wir es deshalb noch nicht versucht, da nichts (z. B. in den Logs) explizit darauf hinwies.

[xchs]

Ja, bei allen mit Safe Mode Hack.

Daran hatten wir auch schon gedacht, konnten aber nichts finden, was einen Zusammenhang herstellen könnte.

Ohne Safe Mode Hack haben wir es deshalb noch nicht versucht, da nichts (z. B. in den Logs) explizit darauf hinwies.

Also, ich würd' auf jeden Fall mittels

AddHandler php5-cgi .php

bzw.

AddHandler php53-cgi .php

auf das CGI-Modul umschalten und grundsätzlich auf den SMH verzichten. Bei allen Paketen, die ich bei All-Inkl hoste, hab' ich damit nur gute Erfahrungen gemacht !

[do_while]

Ich habe auch nur gute Erfahrungen mit der CGI-Version gemacht.

Die localconfig.php wird bei jedem Cron-Lauf (nicht Aufruf) neu geschrieben, da der Cron sich dort den Zeitpunkt des letzten Aufrufs merkt, siehe Source cron.php in TL_ROOT. Wenn es jetzt ggf. kurzzeitige Probleme mit FTP gibt, könnte soetwas dabei herauskommen. Bei CGI fällt diese Fehlermöglichkeit weg.

[HSec]

@do_while
@xchs

vielen Dank für die nützlichen Hinweise!

Wir werden das in den nächsten Tagen abändern (auf CGI umstellen) und die nächsten Wochen beobachten.

Danke und Grüße

HSec

[tofo]

Hallo,

ich habe dieses Problem auch. Meine localconfig.php sieht so aus zur Zeit:

### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '/pfsoe-prager-fotoschule.html';
### INSTALL SCRIPT STOP ###

?> 

Ich habe nix angerührt oder sonst was gemacht, die Installation lief bisher komplett ohne Probleme. contao-check.php ausgeführt, witzigerweise bezeichnet er einige Dateien als korrupt, siehe hier: http://www.lichtbildschmiede.at/contao-check.php

Problem: ich habe kein Backup meiner localconfig.php. Gibt es eine Möglichkeit, diese zu restaurieren oder kann ich den Schmarrn nochmals von vorne anfangen? (Was der Horror wäre)

Gruß, Thomas

[tofo]

Zusatzbemerkung: ich habe auf meinem Server 3 Installation mit Contao, 2 davon mittlerweile kaputt, eine geht noch.

Gruß, Thomas

[xchs]

witzigerweise bezeichnet er einige Dateien als korrupt, siehe hier: http://www.lichtbildschmiede.at/contao-check.php

Das liegt wahrscheinlich daran, dass Du Contao 2.9.0 installiert hast, den System-Check aber mit dem Skript für die Version 2.9.1 machst.

Hast Du auf Deinem Webspace auch noch ausreichend freien Speicherplatz? Gibt es vielleicht irgendeinen Cronjob, der das korrekte Schreiben der Konfigurationsdatei hätte verhindern können?

[lucina]

Keine Panik.

Schau, ob es mit dem Speicherplatz passt.

Schau, was das Serverlog sagt (wir wollen ja wissen was da passiert ist).

Rufe das Installtool auf (zur Not vorher eine frische localconfig.php aus einem Installationspaket aufspielen, vorher die bisherige nach localconfig.php.bak umbenennen), Deine Datenbank und/oder FTP-Daten eingeben, NICHTS importieren. Sollte wieder laufen.

Ggf. dann im Backend die Einstellungen überprüfen.

Carolina.

[tofo]

Zuhause habe ich doch noch eine Sicherung einer Webseite gefunden und aufgespielt. Hab dann im Systemlog nachgesehen, es sind nur Einträge dabei wie "No active page for page ID..." dabei, aber nichts, was auf einen Fehler hinweisen würde. Sehr eigenartig.

Zumindest wieder was gelernt: Backups, Backups, Backups. Werd mir gleich eines einrichten.

Gruß, Thomas

[xchs]

Dieser Eintrag in Deiner "localconfig.php"

$GLOBALS['TL_CONFIG']['websitePath'] = '/pfsoe-prager-fotoschule.html'; 

scheint mir aber auf jeden Fall falsch zu sein. Da sollte doch - sofern überhaupt nötig - eine Pfadangabe zu Deiner Contao-Installation stehen und NICHT ein Dateiname!

[tofo]

Ja, eh - aber da stand nix anderes drinnen als das. Und ich hab daran nix geschraubt, ehrlich nicht!

Sollte mal auf 2.9.1 upgraden, vielleicht ist das Problem dann weg.

Gruß, Thomas

[xchs]

Ja, eh - aber da stand nix anderes drinnen als das. Und ich hab daran nix geschraubt, ehrlich nicht!

Ja, das glaub' ich Dir schon! Die Frage ist nur, wie bzw. warum gerade dieser Dateiname da reingeschrieben wurde... *grübel*

[lucina]

Serverlog

Nicht Systemlog.

[tofo]

Muss ich passen, habe ich gemacht, gegreppt wie der Teufel, nur leider für die Katz. Kein Output, nichts, was auf ein Schreibproblem oder ähnliches von localconfig.php schließen lässt.

Aber, dafür muss ich ein Kompliment aussprechen: das Installationstool zu benutzen, um die localconfig.php wieder herzustellen, ist genial, hat für die zweite Domain echt gut und sauber funktioniert! Danke vielmals für den Tip!

Gruß, Thomas

[radobo]

Hallo, ich habe bzw. hatte das gleiche Problem und kann eindeutig sagen, dass es bei mir mit vollem Speicherplatz zusammenhing. Ich hatte mit einigen Dateiübertragungen das Speichervolumen ausgeschöpft, mir aber nichts dabei gedacht. Am nächsten Tag wollte ich weiterschauen, und da lief meine Seite nicht mehr.
Als Ursache kann ich mir gut vorstellen, dass durch den täglichen Cron-Job, der ja in der Localconfig einen Stempel hinterlässt, die Datei beim Speicherversuch zerstört wurde.

Ich installierte contao vollständig neu, kopierte meine tl-files und die htaccess dorthin und führte das Install-Tool aus - alles wieder wie neu! Aber der Schrecken saß tief!

Übrigens war auch die css-Datei zu dem Zeitpunkt leer (die habe ich auch rüberkopiert). Nach dem ersten Schrecken merkte ich aber schnell, dass diese von contao direkt wieder aufgebaut wird.

Gruß, Reinhard

[lucina]

Als Ursache kann ich mir gut vorstellen, dass durch den täglichen Cron-Job, der ja in der Localconfig einen Stempel hinterlässt, die Datei beim Speicherversuch zerstört wurde.

Das ist die Ursache, und es läuft genau so - wenn dann der Cron aufgerufen wird um das System zu warten, ein Logeintrag generiert wird und der Platz für die localconfig.php nicht mehr reicht passiert exakt das.

Gute Provider versenden eine Speicherplatzwarnung. Auch hier gilt dann: You get what you've paid for. Wer sowas nicht hat muss da eben selbst drauf gucken.

Übrigens war auch die css-Datei zu dem Zeitpunkt leer (die habe ich auch rüberkopiert). Nach dem ersten Schrecken merkte ich aber schnell, dass diese von contao direkt wieder aufgebaut wird.

Die CSS-Dateien im Root werden bei jedem Speichern im Backend / Stylesheets erneut geschrieben. Wenn die weg sind, dann ist das in aller Regel überhaupt kein Problem.

[beatem]

Hallo, genau das gleiche Phänomen trat bei zwei meiner Kundenwebseiten auf, bei einem Kunden wird die Seite mit dem Safe Mode Hack betrieben, beim anderen ohne - daran sollte es dann wohl eher nicht liegen. Die localconfig war leer bis auf diese Zeilen:

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

?>STALL SCRIPT STOP ###

?>

Am Webspaceplatz kann es eigentlich auch nicht liegen, das eine Paket ist lange nicht ausgeschöpft.
Beide Kunden haben die aktuellste Version 2.9.1.
Mit älteren Versionen und gleichen Erweiterungen trat dieses Phänomen nicht auf.

Beides mal traten diese Ausfälle in der Nacht auf....und es sind 2 verschiedene Provider...

Hat jemand vielleicht eine Idee woran es liegen könnte?

Herzliche Grüße
Beate

[timbugto]

Habe das Problem nur einmal gehabt und konnte es nicht reproduzieren bzw. weis nicht woran es lag/liegt.

Man sollte es im Auge behalten...

[beatem]

Hallo, bei mir trat der Effekt bei der einen Seite 2 Tage hintereinander in der letzten Woche und bei der anderen Seite heute Nacht auf...

Ich finde das schon sehr seltsam - Fehlermeldungen kann ich auch nicht finden.

[MacKP]

Hallo beatem,
es könnte helfen noch mal ne frische localconfig.php (neu runter geladene) zu nehmen und diese mit Hilfe von install.php neu beschreiben zu lassen.

Dadurch kannst du dann sicher sein , das kein Fehler mehr enthalten ist. Denn wenn ich mir das da so anschaue:

?>STALL SCRIPT STOP ###

sieht das nicht wirklich richtig aus was du gepostet hast.

Viele Grüße

[beatem]

Hallo,
ich hatte die localconfig seit fast einem Jahr problemlos im Einsatz.

Das hier stand in der Localconfig heute Morgen:

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

?>STALL SCRIPT STOP ###

?>


Jetzt habe ich meine gespeicherte überspielt, worauf die Seite wieder funktioniert hat. Hinterher habe ich diverse Änderungen an den Einstellungen im Backend vorgenommen zum Testen, diese wurden alle fehlerfrei in der localconfig eingetragen.

Also ich glaube nicht dass es an einer fehlerhaften localconfig liegt.

<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');

/**
* TYPOlight webCMS
* Copyright (C) 2005-2009 Leo Feyer
*
* This program is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, either
* version 2.1 of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this program. If not, please visit the Free
* Software Foundation website at http://www.gnu.org/licenses/.
*
* PHP version 5
* @copyright Leo Feyer 2005-2009
* @author Leo Feyer <leo@https://contao.org>
* @package Config
* @license LGPL
* @filesource
*/

### INSTALL SCRIPT START ###

$GLOBALS['TL_CONFIG']['websitePath'] = '';
$GLOBALS['TL_CONFIG']['installPassword'] = 'xyz';
$GLOBALS['TL_CONFIG']['encryptionKey'] = 'xyz';
$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQL';
$GLOBALS['TL_CONFIG']['dbHost'] = 'xyz';
$GLOBALS['TL_CONFIG']['dbUser'] = 'xyz';
$GLOBALS['TL_CONFIG']['dbPass'] = 'xyz';
$GLOBALS['TL_CONFIG']['dbDatabase'] = 'xyz';
$GLOBALS['TL_CONFIG']['dbPconnect'] = false;
$GLOBALS['TL_CONFIG']['dbCharset'] = 'UTF8';
$GLOBALS['TL_CONFIG']['dbPort'] = 3306;
$GLOBALS['TL_CONFIG']['cron_weekly'] = 201041;
$GLOBALS['TL_CONFIG']['latestVersion'] = '2.9.1';
$GLOBALS['TL_CONFIG']['cron_daily'] = 20101011;
$GLOBALS['TL_CONFIG']['installCount'] = 0;
$GLOBALS['TL_CONFIG']['adminEmail'] = 'xyz;
$GLOBALS['TL_CONFIG']['timeZone'] = 'Europe/Berlin';
$GLOBALS['TL_CONFIG']['websiteTitle'] = 'xyz';
$GLOBALS['TL_CONFIG']['rewriteURL'] = true;
### INSTALL SCRIPT STOP ###

?>

[beatem]

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


bei Google ein....ich glaube der Effekt trat schon öfters auf - wurde aber zum größten Teil wieder behoben.

Was mir auch noch auffällt, bei meinen beiden Seiten waren es Seiten mit mod_rewrite.

Ist nur ein Versuch fürs Ausschlußprinzip

[lucina]

Vor ein paar Wochen ist das bei einer meiner Kundinnen ebenfalls passiert, ansatzlos. Da war dann ein ganzer Shop weg.

Welche Extensions setzt Du ein?

Carolina.

[beatem]

Hallo Carolina,
also BackupDB, mod_backlink und newsextend beim einen Kunden, extended_checkbox, Metacreator, mod_backlink und BackupDB beim anderen...

Herzliche Grüße Beate

[lucina]

Bliebe BackUpDB als Schnittmenge - und da sehe ich jetzt nix was automatisch zu Problemen führen könnte.

Hmm, müsste irgendwas sein was die cron.php antriggert (so die Theorie).

[xchs]

Hallo beatem,

hast Du bereits einige der Vorschläge aus diesem Thread geprüft?

Das "Problem" scheint meist im Zusammenhang mit den Contao Cron-Jobs aufzutreten (getriggert per Webseitenaufruf), welche nach entsprechender Ausführung einen Zeitstempel in die "localconfig.php" reinschreiben. Contao-Installationen, bei denen der SMH zum Schreiben der Daten notwendig ist, müssen dafür notwendigerweise FTP-Verbindungen aufbauen. Jetzt könnte es u.U. passieren, dass so eine Verbindung (aus welchen Gründen auch immer) nicht korrekt zustandekommt und daher die Einträge in die "localconfig.php" nicht bzw. nur unvollständig geschrieben werden können. Das ist beispielsweise auch der Fall, wenn es am Server ein begrenztes Speicherplatzkontingent gibt und dieses bereits die Kapazitätsgrenze überschritten hat.

[hajo808]

Hallo!

Also bei mir tritt das Problem nun schon mehr als einmal im Monat auf.
Ich muss jeden Tag gucken ob die Seite noch läuft.
Vor ca. einer Woche, vorgestern und heute trat es wieder auf. Was kann man tun?
Speicherplatz ist zur genüge vorhanden. Ich kann doch nicht jeden Tag nachschauen ob die Seite noch läuft und wenn nicht, die localconfig.php wieder drüber kopieren.

Verwendete Erweiterungen:
avatar, BackupDB, cron, csseditor, cTidy, cTidy_article_cleaner, dark_but_nice, DomainLink, Favicon, graphicalelements, graphicaltext, graphical_navigation, gt-access, guestbook, Imageslider, keywords, newsticker, stylsheets_external, table4ward, videobox, videobox_dailymotion, weeatheronline, xganalytics, xgrid

Help! Das wird langsam zu einem nervenaufreibenden Problem.

[xchs]

Wichtig wär' in diesem Zusammenhang vielleicht auch noch die Info, ob Du den Safe Mode Hack (SMH) verwendest.