Admin-Backend seit Update Internal Server Error 500 [GELÖST]

[tobiwalden]

N'Abend!

Kurz nach dem großen Update (an der Stelle einen großen Dank!) war ich zuletzt im Admin-Backend, um mich vom neuen Design zu überzeugen. Dort hat noch alles problemlos geklappt.
Heute wollte ich zwecks eines vollen Mailpostfachs mich erneut im Admin-Backend anmelden und musste dabei feststellen, dass ich nur noch einen 500 Internal Server Error erhalte.

Da ich seit Wochen nichts selber am Server mehr gemacht habe (war über die Weihnachtszeit im Urlaub) und die Seiten an sich auch alle problemlos funktionieren, gehe ich daher davon aus, dass das ganze etwas mit dem späteren Update auf 18.2.1 zu tun haben könnte.

/var/log/apache2/keyhelp/error.log besteht lediglich aus folgendem Inhalt (davon aber über 100 Einträge):

Code: Select all

[Wed Jan 02 20:39:52.493059 2019] [fastcgi:error] [pid 378] (2)No such file or directory:  FastCGI: failed to connect to server "/home/keyhelp/www/cgi-bin/php5-fcgi": connect() failed
[Wed Jan 02 20:39:52.493095 2019] [fastcgi:error] [pid 378]FastCGI: incomplete headers (0 bytes) received from server "/home/keyhelp/www/cgi-bin/php5-fcgi"

Kann mir hier jemand auf die Sprünge helfen? Ich habe wie gesagt nichts verändert, es sind keine Update verfügbar, habe das ganze System bereits neu gestartet, aber für viel mehr fehlt mir leider das Fachwissen. Der einzig ähnliche Thread hier im Forum hat mir nicht sonderlich weitergeholfen.

So lange Seiten und Mailing an sich laufen, ist noch einigermaßen alles okay, aber wirklich gut kann das hier ja auch nicht sein.

Grüße und frohes Neues!
Tobias

[Blackmoon]

Guten Abend.

Führ einmal folgenden Befehl aus:

Code: Select all

sudo lsof -U | grep php
...
php-fpm7.  1176             root    7u  unix 0x0000000000000000      0t0   23780 /run/php/keyhelp_keyhelp.socket type=STREAM
...

Ist dieser Eintrag vorhanden?

In der Datei /etc/php/7.2/fpm/pool.d/keyhelp.conf sollten folgende Eintrage vorhanden sein:

Code: Select all

[keyhelp]
listen = /run/php/keyhelp_keyhelp.socket
listen.owner = keyhelp
listen.group = keyhelp
listen.mode = 0666
user = keyhelp
group = keyhelp
pm = ondemand
pm.max_children = 10

/Dani

[Fiesi]

Nur mit den unterschied das er auf php5 achten muss und nicht wie du beschrieben hattest php7

Aber KH arbeitet mit php7.0 ? und nicht mit php5 wie es bei dir versucht zu laden?
Sind denn die anderen php Versionen alle noch drauf?

was sagt den php -v inne Console vom Server?

Code: Select all

 php -v
PHP 7.0.33-0+deb9u1 (cli) (built: Dec  7 2018 11:36:49) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.2.1, Copyright (c) 2002-2018, by ionCube Ltd.
    with Zend OPcache v7.0.33-0+deb9u1, Copyright (c) 1999-2017, by Zend Technologies

Es sollte sowas angezeigt werden, wenn was mit php5 oder php7.2 kommt, scheint da etwas "größeres" nicht zu stimmen...

[Martin]

Hallo,

zumindest bei Debian 8 (PHP 5.6) oder Ubuntu 14.04 (PHP 5.5) wäre PHP 5 durchaus normal.

[tobiwalden]

Großen Dank für Eure schnellen Antworten!
Erst etwas beunruhigt, wirft mir php -v doch anscheinend alles korrekt aus:

Code: Select all

php -v
PHP 7.0.30-0+deb9u1 (cli) (built: Jun 14 2018 13:50:25) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.2.1, Copyright (c) 2002-2018, by ionCube Ltd.
    with Zend OPcache v7.0.30-0+deb9u1, Copyright (c) 1999-2017, by Zend Technologies

Da ich damals auf Debian 9 umgestiegen bin, sollte also an für sich alles passen.


sudo lsof -U | grep php liefert mir folgendes

Code: Select all

php-fpm7.   290       root    6r  unix 0xffff88051590e880      0t0 3127394883 type=STREAM
php-fpm7.   290       root    7u  unix 0xffff880e562e4b80      0t0 3127394884 type=STREAM
php-fpm7.   290       root    8u  unix 0xffff880ee1d630c0      0t0 3127394885 /run/php/keyhelp_keyhelp.socket type=STREAM
php-fpm7.   290       root    9u  unix 0xffff880ee1d63440      0t0 3127394888 /run/php/keyhelp_tebewalden.socket type=STREAM

Und in der /etc/php/7.0/fpm/pool.d/keyhelp.conf (7.2 hab ich nicht) sieht auch alles korrekt aus:

Code: Select all

[keyhelp]
listen = /run/php/keyhelp_keyhelp.socket
listen.owner = keyhelp
listen.group = keyhelp
listen.mode = 0666
user = keyhelp
group = keyhelp
pm = ondemand
pm.max_children = 10
pm.max_requests = 0

[Fiesi]

Sagt denn das Apache Log noch etwas beim Neu bez. restarten?

Evtl. mal in die Errorlog schauen.
Und schau dir mal den VHosts eintrag von speziel von KH - viell da was verstellt wenn er versucht auf php5 zuzugreifen?

glaub in der /etc/apache2/keyhelp/keyhelp.conf sollte die Zeile für php so aussehen;

Code: Select all

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/keyhelp_keyhelp.socket|fcgi://keyhelp_keyhelp.socket"
    </FilesMatch>

[tobiwalden]

Das sind die einzigen Einträge nach einem Restart des Servers:

Code: Select all

[Thu Jan 03 11:48:26.220713 2019] [http2:warn] [pid 395] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.
[Thu Jan 03 11:48:26.222691 2019] [:notice] [pid 404] FastCGI: wrapper mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Thu Jan 03 11:48:26.222728 2019] [:notice] [pid 404] FastCGI: process manager initialized (pid 404)
[Thu Jan 03 11:48:26.412822 2019] [mpm_prefork:notice] [pid 395] AH00163: Apache/2.4.25 (Debian) mod_fastcgi/mod_fastcgi-SNAP-0910052141 OpenSSL/1.0.2l configured -- resuming normal operations
[Thu Jan 03 11:48:26.412848 2019] [core:notice] [pid 395] AH00094: Command line: '/usr/sbin/apache2'

Zwecks deinem Hinweis auf die keyhelp.conf: Dort sieht der entsprechende Abschnitt bei mir so aus:

Code: Select all

# php files
    <FilesMatch "\.php$">
        SetHandler php5-fastcgi
        Action php5-fastcgi /php5-fastcgi
        Options +ExecCGI
    </FilesMatch>

Kann ja irgendwie nicht passen, oder?

Es verbleiben jedoch folgende Einträge in der error.log von Keyhelp selbst:

Code: Select all

FastCGI: incomplete headers (0 bytes) received from server "/home/keyhelp/www/cgi-bin/php5-fcgi"

Wenn ich nun mal ins Verzeichnis /home/keyhelp/www/cgi-bin schaue, fällt mir auf, dass mir gar nichts auffällt. Im Ordner cgi-bin sind keinerlei Dateien oder Ordner. Liegt das daran oder bin ich hier auf der falschen Spur?

[Alexander]

Moin,

Wenn du willst, kann ich mal kurz drüber schauen, schick mir dazu einfach die SSH Zugangsdaten per PM.

Zwecks deinem Hinweis auf die keyhelp.conf: Dort sieht der entsprechende Abschnitt bei mir so aus:

Der Eintrag ist unterschiedlich, je nach verwendetem Betriebssystem, von daher muss nicht falsch sein.

EDIT: Hab das mit Debian 9 garnicht gelesen - ja dann ist das natürlich falsch

[Fiesi]

Naja, wenn Debian9 läuft, sollte ja KH theo. auf php7 laufen und nicht auf php5.

Es sein denn, das das nicht geändert wurde und durch nen KH Update viell standard von 5 auf 7 geändert wurde aber der Vhost nicht angepasst wurde dann.

Mal sehen was Alexander sagt woran es lag

[Alexander]

@Fiesi, Hab das mit Debian 9 gar nicht gelesen, von daher hast du natürlich recht, dass das nicht stimmt .


Der Server läuft wieder, ursächlich war eine Manipulation eines Wertes in der Datenbank: Tabelle `settings`, Feld: `php` - `uses_fcgid`. Der Wert stand auf "0" anstatt auf "1" wie es für Debian 9 und Ubuntu 18 der Fall sein muss.

Wodurch diese Änderung ausgelöst wurden ist ist nicht geklärt, von KeyHelp selbst kann dies jedoch nicht erfolgt sein, da KeyHelp nur lesend auf den Wert zugreift. Ggf. ist ein Einspielen eines Datenbank-Backup von Debian-8-Zeiten, oder händische Änderung dafür verantwortlich.
Einzig das Upgrade-Script von Debian 8 zu Debian 9 würde diesen Wert ändern, von von "0" zu "1". Dies ist zum Zeitpunkt des Upgrades auch korrekt erfolgt.

Das Ganze fiel deshalb nach dem Update auf KeyHelp 18.2.1 auf, da in diesem Zuge die /etc/apache2/keyhelp.conf neu geschrieben wurde.
Da der Wert in der Datenbank falsch war, wurde das falsche Konfigurations-Template geladen, was wiederum zum 500-Fehler führte.