[Gelöst] Adminbereich nicht aufrufbar

antiheld2000 · 31. Oktober 2016 10:16

Moin, Moin,

ich habe hier einen Webserver mit PHP 5.6.26. Auf diesem laufen mehrere CMS-Installationen. Das Frontend läuft bei jeder Installation. Das Backend läuft bis CMS Version 1.11.2 problemlos. Ab CMS 1.11.13 wird mir nach Klick auf den Anmelden-Button bei korrekten Anmeldedaten eine Fehlerseite des Hosters angezeigt. Im error_log tritt dann folgendes auf:

error_log schrieb:

[Tue Oct 25 15:15:21.531799 2016] [core:notice] [pid 9790] AH00052: child pid
28923 exit signal Segmentation fault (11)
[Tue Oct 25 15:15:26.539121 2016] [core:notice] [pid 9790] AH00052: child pid
17743 exit signal Segmentation fault (11)

Der Support des Providers sagt, dass liegt irgendwie am Script. Tja, und da steh ich nun planlos. Hat jemand eine Idee, was ich mal untersuchen könnte oder wie ich weiter vorgehen könnte, um das Problem zu finden und danach dann vielleicht sogar die Lösung des Problems?

Mit Dank und Gruß
anti

Beitrag geändert von antiheld2000 (01. November 2016 21:33)

NaN · 01. November 2016 15:18

dass liegt irgendwie am Script.

Ja nee ist klar.
Wie ich solche Provider liebe.
Wenn ich mal nach der Fehlermeldung suche, dann bekomme ich verschiedene Beiträge zum Thema Server-Konfiguration. Nix PHP-Script. Meist ist es der Apache oder PHP was da ganz krass abschmiert. Da dieser Fehler nicht abgefangen werden konnte, muss er also irgendwie tiefer im System sein. D.h. nicht auf Script-Ebene.

Meines Wissens entsteht dieser sogenannte "Segmentation fault" im Zusammenhang mit Apache/PHP meistens dann, wenn auf Speicherbereiche zugegriffen wird, die nicht dem jeweiligen Prozess zugeordnet sind. Kann auch sein, dass ein wichtiger Prozess gekillt wurde, weil zu wenig RAM (SERVER-RAM nicht PHP-RAM) verfügbar war (Stichwort OOM-Killer). Darauf hat man aber auf Script-Seite mal so ziemlich null Einfluss. Sowas kann z.B. passieren, wenn irgendein PHP-Modul fehlerhaft ist. (Ein Upgrade bzw. eine Neuinstallation könnte da helfen - gibt auch Berichte von fehlerhaften Upgrades). Im schlimmsten Fall passiert sowas aber auch mal bei defekter Hardware. Wie dem auch sei, ohne einen CoreDump ist es ziemlich schwer, das zu debuggen.

Google spuckt auch verschiedene mögliche Lösungen aus wie z.B.
- MaxRequestsPerChild erhöhen
- output_buffering erhöhen
- Syntaxfehler in der php.ini (Einheit beim Memorylimit vergessen)
- diverse PHP-Module testweise deaktivieren bis man den Schuldigen hat
- zu viele vHosts

Das kann alledings nur jemand machen, der Zugriff auf den Server hat, weil man Apache dazu neustarten muss. Also frag mal ganz lieb Deinen Provider, wie man das am besten debuggen und lösen könnte.

Eine mögliche weitere Lösung wäre ... wenn ich mal ganz krumm um die Ecke denke ... also es gibt auch Berichte, dass dieser SegFault beim Öffnen von Remote-Dateien (also bei HttpRequests vom Server zu anderen Servern) z.B. via file('http://www.adresse.tld'); auftreten soll. Da der Fehler ja nur im Backend auftritt, und im Backend nach dem Login als erstes nach einer neuen CMS-Version gesucht wird, kann es also sein, dass man nur diese Zeilen im PHP-Script deaktivieren muss.

Z.B. in der Datei /admin/header.php Zeilen 78 bis 105 deaktivieren:

Hier klicken, um den Code zum Kopieren zu markieren

	$timelastchecked = get_site_preference('lastcmsversioncheck',0);
	if( (get_site_preference('checkversion',1) && (time() - $timelastchecked) > (24 * 60 * 60)) || isset($_GET['forceversioncheck']) )
	  {
	    $req = new cms_http_request();
	    $req->setTimeout(10);
	    $req->execute(CMS_DEFAULT_VERSIONCHECK_URL);
	    if( $req->getStatus() == 200 )
	      {
		$remote_ver = trim($req->getResult());
		if( strpos($remote_ver,':') !== FALSE )
		  {
		    list($tmp,$remote_ver) = explode(':',$remote_ver,2);
		    $remote_ver = trim($remote_ver);
		  }
		if( version_compare(CMS_VERSION,$remote_ver) < 0 )
		  {
		    set_site_preference('cms_is_uptodate',0);
		    $themeObject->AddNotification(1,'Core',lang('new_version_available'));
		    audit('','Core','CMSMS version '.$remote_ver.' is available');
		  }
		else
		  {
		    set_site_preference('cms_is_uptodate',1);
		    audit('','Core','Tested for newer CMSMS Version. None Available.');
		  }
	      }
	    set_site_preference('lastcmsversioncheck',mktime(23,59,55));
	  }

Würde mich allerdings eher wundern, wenn das tatsächlich des Rätsels "Lösung" wäre, weil sich daran in der 1.11er Reihe nichts geändert hat. Aber als Ansatz könnte es schon helfen, wenn man einfach mal gedanklich alle Admin-Seiten durchgeht, und prüft, was genau im Backend anders läuft als im Frontend. Vielleicht kommt man ja so auch schon auf den Schuldigen. Es könnte z.B. auch irgendein Modul sein. Module kannst Du ja testweise "deaktivieren" indem Du die entsprechenden Modul-Ordner via FTP Stück für Stück umbenennst.

antiheld2000 · 01. November 2016 15:51

Leider bin ich gerade auf dem Sprung, aber ein fettes Danke muss ich sofort mal loswerden und deine Idee mit der header.php hat auf die Schnelle bei einer Installation auf jeden Fall gefruchtet. JUHU! Ich werde es aber noch einmal genauer versuchen und dann weiter berichten. Tausend Dank soweit! Lifesaver!

antiheld2000 · 01. November 2016 21:32

So, nachdem ich jetzt mal alle Installationen durchgegangen bin, habe ich dank der Idee von NaN überall die entsprechenden Zeilen in der admin/header.php auskommentiert. Danach konnte ich mich problemlos eingeloggen und unter den globalen Einstellungen die regelmäßige Prüfung auf neue CMSMS-Versionen deaktivieren. Danach hat alles wieder wie vorher funktioniert. Bisher keine Module oder Funktionen entdeckt, die den Fehler wieder hervorrufen. Dickes, fettes Danke an NaN!

NaN · 02. November 2016 18:46

Auch wenn es mich freut, dass Dein Problem damit überraschenderweise zunächst behoben ist (ehrlich, überrascht mich selbst yikes ) , solltest Du das mal als Info an Deinen Provider weiterleiten. Denn das ist keine Lösung, sondern eher das Umgehen eines ernsthafteren Problems. Irgendwie scheint der Server Probleme mit cUrl zu haben (das ist die Funktion, die CMSms nutzt, um eine Verbindung zum Download-Server aufzubauen und nach neuen Versionen zu suchen). Wenn ich im Netz nach "PHP cUrl segmentation fault" suche, dann erhalte ich sehr viele Bugreports, die sich größtenteils auf eine fehlerhafte Bibliothek (libcurl) beziehen. In den meisten Fällen hat dort cUrl ein Problem mit SSL-Urls. Allerdings scheint der Fehler mal im Betriebssystem und mal bei PHP zu liegen. Außerdem wird bei CMSms im Backend beim Prüfen der Versionsnummer keine SSL-Url aufgerufen.

Wenn Du Zeit und Lust hast, erstelle Dir mal auf einem der Webspaces bei denen das Problem auftrat, eine PHP-Datei mit folgendem Inhalt:

Hier klicken, um den Code zum Kopieren zu markieren

<?php

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://www.cmsmadesimple.org/latest_version.php");
$result = curl_exec($ch);
curl_close($ch);
echo $result;

?>

Als Ergebnis sollte Dir die neueste verfügbare Versionsnummer von CMSms ausgegeben werden.

Wenn das wider Erwarten funktionieren sollte, versuch das gleiche nochmal, aber mit https.

Wenn eines davon fehlschlägt, kannst Du es Deinem Provider direkt unter die Nase reiben.
Dann stimmt definitiv etwas mit seinem System nicht.
Denn diese vier Zeilen sind kein großes Voodoo.
Zumindest dürfte es nicht in einem SegFault enden.

Falls beides klappt, liegt der Fehler doch woanders.
Wo er dann liegen könnte, da hab ich noch keine Idee.

Sollte der Fehler tatsächlich nur bei SSL-Urls auftreten, dann gibt es da noch Berichte, bei denen man im Script für cUrl einfach nur eine bestimmte Option setzen muss, damit der Fehler nicht mehr auftritt. Man muss cUrl explizit sagen, welche SSL-Version verwendet werden soll.

Dazu in der Datei /lib/classes/class.cms_http_request.php nach Zeile 887:

Hier klicken, um den Code zum Kopieren zu markieren

			curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);                // No certificate

Eine dieser Zeilen einfügen (mal ausprobieren, welche klappt):

Hier klicken, um den Code zum Kopieren zu markieren

			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv2);
			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv3);
			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_0);
			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_1);
			curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

Wenn nichts davon hilft oder Dein Provider keine Lust hat, dann belasse es einfach mit der deaktivierten Option. (Du weißt ja selber, dass CMSms 1.11 schon ein Weilchen alt ist. Da muss Dir keiner ständig sagen, dass es neue Versionen gibt wink )

Beitrag geändert von NaN (04. November 2016 13:37)

antiheld2000 · 03. November 2016 08:32

Erneut vielen Dank für deine Mühe. Deine Vermutung war richtig, dass es mit curl zusammenhängt. Der segmentation fault trat bei Aufruf deines Beispielskripts erneut auf. Ich habe dem Provider nochmal gemailt und warte derweil auf Nachricht. Der Webspace ist extra für die Kunden, die es nicht einsehen, dass man so ein System mal updaten muss und dafür auch nicht bezahlen wollen. Deswegen die veralteten Versionen. Mal sehen, wie lange das gut geht …

Andynium · 03. November 2016 18:59

NaN schrieb:

Da der Fehler ja nur im Backend auftritt, und im Backend nach dem Login als erstes nach einer neuen CMS-Version gesucht wird, kann es also sein, dass man nur diese Zeilen im PHP-Script deaktivieren muss.

Nix Core hacken tongue ...

if( (get_site_preference('checkversion',1) && ...

Lässt sich doch im Backend deaktivieren big_smile - Administration > Webseiteneinstellungen > Globale Einstellungen > Weitere Einstellungen -> "Regelmäßig auf neue CMSms-Versionen prüfen"

owr_web · 03. November 2016 19:59

Hatte er danach gemacht wink

Wer das Problem also hat und nicht den core hacken will um die Einstellung zu ändern kann es auch über die Datenbank machen

Tabelle "_siteprefs" -> Eintrag "checkversion" von 1 auf 0 ändern und es flutscht auch wieder.

Andynium · 03. November 2016 20:08

Ist bei meinen Installationen als Default deaktiviert big_smile ... macht nur die Kunden unnötig nervös, wenn plötzlich eine ungewohnte Meldung auftaucht.

NaN · 03. November 2016 21:58

Lässt sich doch im Backend deaktivieren

Ja, aber wenn man, wie in der Überschrift schon vermerkt, nicht mal mehr ins Backend kommt, hilft das nicht weiter. Dann geht entweder nur noch der Weg übers hacken oder über die DB. Da ich ja nicht wusste, ob ich da überhaupt richtig liege, wusste ich auch nicht, welche Option man wo deaktivieren muss.

Mich würde ja mal interessieren, ob die Option "CURLOPT_SSLVERSION" irgendwas gebracht hat. Wenn ja, dann wäre ein Hack doch sehr sinnvoll, oder?

Andynium · 03. November 2016 22:03

NaN schrieb:

Mich würde ja mal interessieren, ob die Option "CURLOPT_SSLVERSION" irgendwas gebracht hat. Wenn ja, dann wäre ein Hack doch sehr sinnvoll, oder?

+1

Wenn dieses PHP-Modul bzw die Funktion gar nicht verfügbar ist, wäre es optimal, wenn zum einen die Möglichkeit zum Einstellen im Backend gar nicht vorhanden ist, und zum anderen die Funktion überhaupt nicht ausgeführt wird.

Nehm es mal mit auf die Feature-Liste...

antiheld2000 · 04. November 2016 08:54

Tja, der Fehler tritt nun leider nur noch "random" auf, so dass die Angestellten Techniker beim Provider den Fehler bisher nicht reproduzieren konnten. Da ich ihn aber reproduzieren konnte, bat ich um erneute Prüfung. Mit Glück wird es dann ja mal eine Info vom Provider geben. Ich werde dann hier mal was verlautbaren.

antiheld2000 · 04. November 2016 11:10

Was dem Support und mir gerade mal aufgefallen ist: Die URL http://www.cmsmadesimple.org/latest_version.php ist bei einigen Tests recht häufig nicht erreichbar. Das hängt doch bestimmt irgendwie zusammen oder?

NaN · 04. November 2016 14:09

Hab in meinem Beispielscript das "curl_close($ch);" vergessen.
Aber das sollte keine Auswirkungen haben.

Ich denke nicht, dass die Erreichbarkeit der URL etwas mit dem SegFault zu tun hat. Wie das Ergebnis der Anfrage aussieht, kann dem Prozess ja egal sein. Erstmal muss er sie ausführen können. Die URL ist bei meinen Tests eigentlich immer recht flott da. Aber zum Testen kann man ja auch irgendeine andere URL nehmen.

Kleiner Tipp an Deinen Support: Wenn cUrl via Kommandozeile funktioniert, dann liegt das Problem an Apache.

Ich muss hier mal weiter raten:

Wann trat das Problem bei Dir auf? Hat Dein Provider in letzter Zeit ein Update von Apache vorgenommen? (z.B. auf Apache 2.4)

Es gibt nämlich Berichte, dass sich das Verhalten von Apache 2.4 bei HTTP-Requests geändert hat. Irgendwie haben die etwas an ihrer API geändert, was vielleicht nicht von jedem Modul-Entwickler bemerkt wurde. Ich verstehe da allerdings nur Bahnhof.

Vielleicht wird Dein Support ja hieraus schlauer:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56984#c1
https://bugs.php.net/bug.php?id=69218

Andynium · 04. Dezember 2016 07:35

antiheld2000 schrieb:

Mit Glück wird es dann ja mal eine Info vom Provider geben. Ich werde dann hier mal was verlautbaren.

Ist da irgend etwas erhellendes heraus gekommen?

Forum für CMS/made simple

#1 31. Oktober 2016 10:16

[Gelöst] Adminbereich nicht aufrufbar

#2 01. November 2016 15:18

Re: [Gelöst] Adminbereich nicht aufrufbar

#3 01. November 2016 15:51

Re: [Gelöst] Adminbereich nicht aufrufbar

#4 01. November 2016 21:32

Re: [Gelöst] Adminbereich nicht aufrufbar

#5 02. November 2016 18:46

Re: [Gelöst] Adminbereich nicht aufrufbar

#6 03. November 2016 08:32

Re: [Gelöst] Adminbereich nicht aufrufbar

#7 03. November 2016 18:59

Re: [Gelöst] Adminbereich nicht aufrufbar

#8 03. November 2016 19:59

Re: [Gelöst] Adminbereich nicht aufrufbar

#9 03. November 2016 20:08

Re: [Gelöst] Adminbereich nicht aufrufbar

#10 03. November 2016 21:58

Re: [Gelöst] Adminbereich nicht aufrufbar

#11 03. November 2016 22:03

Re: [Gelöst] Adminbereich nicht aufrufbar

#12 04. November 2016 08:54

Re: [Gelöst] Adminbereich nicht aufrufbar

#13 04. November 2016 11:10

Re: [Gelöst] Adminbereich nicht aufrufbar

#14 04. November 2016 14:09

Re: [Gelöst] Adminbereich nicht aufrufbar

#15 04. Dezember 2016 07:35

Re: [Gelöst] Adminbereich nicht aufrufbar

Fußzeile des Forums