Die CMSMS-Doku hat wieder zugeschlagen und dadurch hab ich gestern einen kompletten VSERVER mit mehr als 20 Domains in den Abgrund gerissen!

1. der debug-mode wird aktiviert durch Einbinden von {debug} in ein Dokument.
2. Dadurch erhält man Systeminformationen, Warnungen etc.

Das habe ich in einem Dokument aktiviert.
Resultat? 

- Der VServer hing.
- keine der Domains ging mehr
- der Mailserver war down...

der VSERVER musste neu gestartet werden. Dazu musste der Provider ran, am Samstag!

Danach passierte es wieder.
Insgesamt 3x! Bis ich auf die Ursache kam ;=(

Und warum?



Ja kann man denn nicht in die Doku schreiben, daß der Modus aktiviert sein soll? Ein kleiner Satz!!!!!
Ja kann man denn nicht abfangen, daß nichts geschieht wenn der Modus deaktiviert ist?
Ja wird erwartet dass man alle Config-Einstellungen auswendig weiß und deren Bedeutung permanent verinnerlicht hat?

Selbst in der Systeminfo aus dem Admin-Backend wird diese Einstellung nicht angezeigt....

Deshalb schreibe ich das hier als Warnung. Paßt auf!

Ähmm, dass die Doku noch Lücken hat, weiß ich ... aber {debug} ist ein reiner Smarty Tag und hat als solcher primär nix mit CMSms zu tun. Daher wäre smarty.net die richtige Such-/Fundstelle gewesen .

http://www.smarty.net/manual/de/chapter ... onsole.php

Und dort wird schon auf die Zusammenhänge hingewiesen:



In CMSms ist $debugging dann via $config['debug'] eingebunden.

Danke für den wertvollen Hinweis, ist mir in dieser dramatischen Form auch noch nicht bekannt gewesen ... werd gleich mal schauen, wo ich es passender Weise in die Doku einfließen lassen kann.

PS: Was hast du für einen seltsamen Provider, wenn du diesen für einen Neustart brauchst? Du solltest doch da selbst root-Zugriff haben  ...

OK, habs hier eingebaut

http://www.cmsmadesimple.de/cmsms-suppo ... suche.html

Hallo cyberman,

ich hab keinen seltsamen Provider, ich hab einen besonders hilfreichen Provider und ich habe einen "betreuten VSERVER" für den Kunden, weil ich mich in den Dingen der Konfiguration etc. nicht sicher genug fühle.

Und der war so hilfreich und hat mir den VSERVER 3x neu gestartet.

Ja, das ist ein Smarty Tag. Aber wenn CMSMS eine Konfigurationseinstellung dafür hat, dann sollte auch die Doku auf den Zusammenhang und die Notwendigkeit hinweisen. Ich denke, ein Anwender wird nicht auch noch die Smarty-Dokumentation verstehen müssen, um ein von CMSMS propagiertes Tag anzuwenden.

Danke, dass du das in die Doku eingebunden hast!

Hab einen guten Tag!

Ich versteh schon, was du meinst - wer allerdings {debug} verwendet, dem unterstelle ich mal, dass er mit Smarty nicht dass erste mal arbeitet . Kann mich ad hoc jetzt auch nicht erinnern, dass dieser Tag hier im Forum propagiert wurde.

Ist ja jetzt auch egal ... nur durch solche Hinweise kann die Doku optimiert werden - CMSms ist ja schließlich ein Community-Projekt . Manchmal wird man eben auch selbst etwas betriebsblind - vielen Dank nochmals!

naja, dieser Tag ist in der Doku und wenn man etwas ausprobieren möchte, wird auch ein Anwender, der von Smarty nicht viel weiß, das mal so einsetzen. Kann ja nichts schaden ... denkt man.

Ich meine, wäre es nicht möglich, diesen Tag nur dann auszuführen, wenn in der config.php die Option aktiviert ist?
Das wäre eine Prüfung, die auf CMSMS-Seite Unheil verhindern kann. Andere Config-Settings werden ja auch abgeprüft.

Gruss, Connie

Die Prüfung muss aber im Plugin stattfinden, da CMSms nicht weiß, welche Vorraussetzungen die Plugins benötigen.
Dass CMSms bisher nicht geprüft hat, ob gerade {debug} ausgeführt werden soll und ob evtl. in der config.php diesbezüglich etwas falsches stehen könnte, liegt womöglich daran, dass noch niemandem der Server durch {debug} und $config['debug'] = false abgestürzt ist.

Ich habe das eben mal lokal ausprobiert und mein Rechner ist nicht abgestürzt.
Ich habe lediglich in der Debug-Ausgabe als es um das $gCms Objekt ging die Meldung bekommen, dass versucht wurde, zuviel Speicher zu reservieren. (64MB Grenze war erreicht) Und danach wurde abgebrochen.
Die Fehlermeldung mit dem Speicherlimit beschränkt sich auf die Datei modifier.debug_print_var.php.
Offenbar versucht Smarty {debug} mit Hilfe eines Modifikators das komplette Objekt auszulesen, aber scheitert dabei womöglich an auftretenden Rekursionen. (Auch wenn es anders klingt, ich hab von sowas eigentlich überhaupt keine Ahnung )

Erst als ich den Server so konfiguriert hatte, dass jedes Script beliebig viel Speicher konsumieren durfte, ist mir der Webserver abgeschmiert und hat natürlich auch den kompletten Rechner in Mitleidenschaft gezogen. (Was zu erwarten war. Glücklicherweise konnte ich mit etwas Geduld den Websever killen ohne den kompletten Rechner neu starten zu müssen)

Das gleiche ist mir übrigens auch mit $config['debug'] = true passiert. Also scheint es da keinen unmittelbaren Zusammenhang zu geben.
Was mir sagt, dass sich CMSms offenbar generell nicht mit dem {debug} Plugin verträgt.
(Ich vermute mal endlose Rekursion.)
Ich habe aber keine Ahnung, ob der Fehler jetzt im Plugin oder bei CMSms liegt.

Bzw. ist der Fehler eventuell auch einfach nur in der Serverkonfiguration zu finden.
Denn wie gesagt, unter "normalen" Bedingungen lieferte {debug} bei mir zwar keine zufriedenstellenden Ergebnisse (bricht halt irgendwann mittendrin ab), macht aber auch keinen Unfug.
Was mich zu der Frage bringt, in welcher Umgebung und unter welchen Bedingungen Deine CMSms Installationen laufen.
Der Grund für den Serverabsturz kann meiner Meinung nach nicht allein beim Plugin bzw. CMSms iegen.

Da {debug} nichts mit CMSms zu tun hat und CMSms nicht prüft welche Plugins gerade ausgeführt werden sollen und, selbst wenn es das täte, zudem auch (noch) keine Blacklist hat, welche Plugins unter welchen Bedingungen unter welchen Umständen ausgeführt werden dürfen, ist der Fehler hier nicht unbedingt bei CMSms bzw. seiner Dokumentation zu suchen.

{debug} nur auszuführen, wenn $config['debug'] = true ist, scheint meiner Erfahrung nach aber nicht zwingend nötig zu sein, um einen Serverabsturz zu verhindern bzw. scheint es das unter bestimmten Bedingungen auch garnicht zu tun. Das sollte man mal etwas genauer unter die Lupe nehmen.

Jedenfalls sind alle Beteiligten jetzt um eine wertvolle Information reicher.
Tut mir leid, dass Du das auf diese Weise erfahren musstest.
Aber irgendwen hätte es bestimmt so oder so getroffen.

Vielleicht sollte man an den Stellen in der Doku, an denen {debug} erwähnt wird besser nur die config.php und die Einstellung $config['debug'] = true nennen.

Um mal eine präzise Fehlermeldung zu erstellen - mit welcher CMSms-Version ist dieses Problem aufgetreten?

Also bei mir wars CMSms 1.7 unter PHP 5.2.13.
War eine frische Installation ohne weitere Module.

huch, ich komm ein bisschen spät, aber es war CMSMS 1.6.7

Trotzdem danke für deine Rückmeldung - hat mich daran erinnert, den vermeintlichen Bug mal "auf dem kurzen Weg" an das Dev-Team heranzutragen ... hatte allerdings auch mit mehr Rückmeldungen gerechnet.