Beiträge von weltmeister

Bin auch dafür, hierzu gab es schon etliche Kundenanfragen.

Zitat von antondollmaier

Eventuelle Hinweise in "dmesg"/journal zu Segfaults in den Binaries, die entweder kaputt sind oder auf kaputten RAM hinweisen könnten?

Nein, was ich ganz vergessen hatte: diese Konfiguration ist auf mehreren Servern identisch, teilweise mit älterer, aber teilweise auch mit nagelneuer Hardware, wenige Tage alt. Das Problem besteht leider überall gleich.

Ich benötige Hilfe bei der FastCGI-Konfiguration. Es erscheint auf einigen Webseiten des Servers spradisch, also lediglich verzeinzelt ein "Error 500 / Internal Server-Error". Lädt man die Seite anschließend neu oder man drückt F5 ist der normale Inhalt der Webseiten zu sehen.

Betriebssystem: Debian 9, aktuell
PHP-Versionen: 7, 7.2 und 7.3
LiveConfig: ist aktuell (Ich weiß, LiveConfig hat mit diesem Fehler nichts zu tun )
Betroffen u.a.: Shopware- oder Wordpress-Installationen
Memory-Limit, Timeout-Limits in der php.ini: alles sehr großzügig eingestellt.

Fehlermeldungen aus dem error.log:

Zitat

mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer
End of script output before headers: index.php, referer:
mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:
Connection reset by peer: [client xx.xxx.xxx.xxx:18009] mod_fcgid: error reading data from FastCGI server, referer

Aktuelle Konfiguration der /etc/apache2/mods-available/fcgid.conf:

<IfModule mod_fcgid.c>
FcgidConnectTimeout 600
FcgidBusyTimeout 3600
FcgidIOTimeout 3600
FcgidConnectTimeout 600
FcgidMaxRequestLen 314572800
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 4000
FcgidProcessLifeTime 3600
FcgidMinProcessesPerClass 1
FcgidIdleTimeout 100
FcgidIdleScanInterval 240
FcgidMaxRequestsPerProcess 4000
FcgidFixPathinfo 1
FcgidOutputBufferSize 0
FcgidMaxProcessesPerClass 100
<IfModule mod_mime.c>
AddHandler fcgid-script .fcgi
</IfModule>
</IfModule>

Ich habe schon vieles pobiert und etliche Feinschliffe vorgenommen, ein anderer Administrator hat sich auch schon die Zähne hieran ausgebissen. Hat jemand DEN entscheidenden Tipp, wie man diesen Fehler wieder los wird? Falls das jemand liest, der die Sache geben Bezahlung beheben kann: bitte gern eine PN an mich.

Es wäre schön, wenn soetwas künftig ohne Bastelarbeiten in der Datenbank direkt in der Oberfläche steuerbar wäre.
Auch wenn man z.B. alte PHP-Versionen löscht, muss man immer wieder in die Datenbank eingreifen, was sehr umständlich ist. Auch hier ist eine Lösung gefragt!

Hat jemand eine kurze und knappe Anleitung parat? Mit der Umstellung auf "FPM" in den Angeboten allein ist es ja nicht getan. Es kursieren im Internet teilweise verschiedene Anleitungen, die untereinader variieren.

Welche Erweiterungen, z.B. für PHP7 müssen noch installiert und aktiviert werden, damit alles reibungslos über die Bühne geht?

Wurde erledigt, die Datei wird neu erstellt, mit neuem, also aktuellen Inhalt.

Die Anzeige im LiveConfig bleibt aber trotzdem leer.

ps aux | grep lclogparse
---> Dienst läuft

/var/lib/liveconfig/smtp.stats
---> ist überall aktuell und vorhanden, jeweils mit Inhalt

/etc/liveconfig/lclogparse.conf
---> ist überall gleich

...dennoch ist die Anzeige in LiveConfig leider leer.

Zitat von kk

Bitte prüfen Sie, ob auf den betroffenen Servern der Prozess "lclogparse" läuft (der kümmert sich darum, aus den Mail-Logs die Statistiken zu erzeugen).

Laut "systemctl status lclogparse.service" läuft der Dienst, schon seit Tagen / Wochen.
Was könnte noch die Ursache sein?

Siehe Bild: https://www.bilder-upload.eu/upload/9a67fe-1548703417.png

Wo ist hier der Fehler? (Auf dem Server befinden sich 100 Kunden-Accounts, d.h. es sollte hier aif jeden Fall etwas angezeigt werden.)

Nachtrag: das Problem tritt auf 3 von 50 Servern auf Betriebssystem Debian 9.

Gibt es schon etwas neues?

Momentan geht die Entwicklung für viele gewünschte Erweiterungen sehr schleppend voran... oder täuscht das?

Würden viele unserer Kunden auch begrüßen, hier gab es schon gefühlte 100 Anfragen deswegen.

Gibt es schon etwas neues hierzu?

Zitat von mjk

Ich hänge mich hier mal mit meiner Frage dran:
Gibt es mittlerweile Planungen, interne Migrationen im LiveConfig-Cluster durchführen zu können? Also beispielsweise einen Vertrag von Webserver1 auf Webserver2 zu verschieben, identisches mit Datenbanken, Emails usw.?

Ich schließe mich der Frage an!

Das Problem kann ich bestätigen, wird dies bald angepasst?

Ich muss das Thema noch einmal "ausgraben": obwohl der Dienst nicht aktiv ist, wird dieser von LiveConfig als aktiv erkannt. Das sollte so natürlich nicht sein. Der Haken sollte nur aktivierbar sein, wenn Spamassasin tatsächlich auch aktiv und gestartet worden ist.

Zitat von lebenszeit

GAnz ehrlich, GUI ist schön aber für einmalige Einstellungen ist es gut zumutbar, dies in der DB zu bewerkstelligen. Es gibt wichtigeres.

Das ist Wichtig, da den Haken viele Kunden einfach übersehen und im Nachhinein meckern, weil viel Spam kommt.

Nachtrag: habe die Ursache schon gefunden: die Datei /etc/apache2/conf-enabled/liveconfig.conf hatte gefehlt, warum auch immer...

Nach einem Upgrade von Debian 7 auf 9 lief bisher alles problemlos, außer dass auf einem der Server die access.log-Dateien leer sind, bzw. nicht "befüllt" werden. (Größe 0 KB).

Hat jemand eine Idee, wo man zuerst nach der Ursache schauen sollte?

(Die globalen Logs unter /var/log werden hingegen tadellos erzeugt, das Problem besteht nur bei Kundenlogs, wie z.B. /var/www/web1/logs/access.log)

Die Datei /etc/apache2/conf-available/liveconfig.conf ist vorhanden.

Zitat von kk

Das geht durch Anlegen bzw. Ändern der entsprechenden Werte in der LiveConfig-Tabelle LCDEFAULTS:
http://www.liveconfig.com/de/h…advanced.lcdefaults.xhtml

In diesem Fall: mail.autoconfig.default, mail.greylisting.enabled, mail.spam.enabled

Wir planen bereits, diese Einstellungen längerfristig auch über die Weboberfläche konfigurierbar zu machen.

Wann ist es hier soweit?

Wird diese Sache demnächst bitte mit umgesetzt? Selbst zu Confixx-Zeiten gab es das schon.