Webserver crasht beim Speichern auf WordPress Seite

  • Hallo zusammen,


    seit kurzer Zeit habe ich folgendes Problem:


    Wenn ich in einer WordPress Installation (via Plesk installiert) einen Beitrag speichere, dann kann es dazu kommen, dass der Webserver auf Port 80 einfach abstürzt.

    Plesk unter Port 8443 ist weiterhin verfügbar, aber alle anderen Seiten auf Port 80 sind unreachable.


    Einträge in nginx oder Apache Error Log gibt es keine.


    Ich nutze die folgende Software / Einstellung:


    PHP 7.4.10 & FPM Applikation via nginx

    Apache 2.4.29-1ubuntu4.14

    nginx 1.18.0-v.ubuntu.18.04+p18.0.30.0+t200826.0942


    Vor einiger Zeit hatte ich ein ähnliches Problem, jedoch hatte ich bislang nicht damit in Verbindung gebracht:

    Ich ließ vor einiger Zeit eine nextcloud als docker-Image laufen und hab sie via nginx nach draußen geproxied. Als ich versuchte, viele Dateien hochzuladen, war dieselbe Folge zu beobachten.

    Auch hier fand ich in den Logs keine mögliche Ursache.


    Viele Grüße

  • Keine Fehlermeldung glaube ich dir einfach nicht. Wenn unter systemd ein Dienst abstürzt, dann bekommst du auf jeden Fall eine Fehlermeldung im Log.

  • Hallo,


    ich habe nie gesagt, dass es keine Fehlermeldung gibt.

    Nur gibt es zum Zeitpunkt des Absturzes weder im syslog, kernel.log, error.log, Plesk panel.log, Log des Apachen und nginx Einträge.


    Da unter Port 80 der nginx läuft und der 8843 von Plesk bei einem Absturz scheinbar nicht betroffen ist, vermute ich ein Problem beim nginx, der beschwert sich jedoch nicht.


    Nachtrag: Nachdem ich den nginx deaktiviert habe, gab es im Apache error_log schließlich einen Hinweis (der ggf. auch schon vorher da war, nur untergegangen ist ;) )

    Code
    1. [Mon Sep 21 13:36:15.265715 2020] [mpm_event:notice] [pid 1564:tid 140607553932224] AH00491: caught SIGTERM, shutting down
  • Wenn du PHP als FPM ausführst, dann beschwert sich nginx nur über denn kaputten Socket zu PHP FPM. Je nachdem wie der Servwr aufgesetzt wurde, startet letzteres durch systemd komplett neu oder ersetzt den kaputten Worker. Dort kannst du das Logging dann höher drehen bzw. in php selbst.


    journaltctl loggt hier wirklich nichts mit?

  • Ich kann das Problem mittlerweile reproduzieren, aber der Log ist zu dem Zeitpunkt absolut still, auch der journalctl.


    Sobald ich mich auf einer WordPress Seite befinde, die den siteOrigin Page Builder (zum Live-Anordnen von Widgets auf einer Seite) nutzt und diese 3x neulade, stürzt der Webserver ab.


    Nach einer Recherche gibt es potenziell Probleme bei bestimmten PHP-Modulen. Der Workaround ist natürlich, dieses Plugin zu deinstallieren.

    Aber falls das woanders wieder auftritt, hilft das natürlich wenig. PHP-Error-Logs haben auch nach direktem Auslösen keine neuen Einträge leider.

  • Liebes netcup-Forum,


    ich habe vielleicht ein ganz ähnliches Problem und würde mich sehr über Hilfe von Euch freuen.


    Ich versuche jetzt schon die ganze Zeit eine Seite im wordpress-Backend zu aktualisieren oder Änderungen zu speichern. Leider werden meine Änderungen nicht übernommen. Auch das Anlegen und bearbeiten von neuen Seiten funktioniert nicht.

    Der Fehler trat auf nachdem ich versucht habe, die bearbeitete Seite in der Vorschau zu sehen. Meine Seite wurde als "Entwurf" gespeichert, ohne dass ich hierzu etwas beigetragen hätte.


    In der error_log habe ich nur folgendes gefunden: [Wed Sep 23 06:27:10.748508 2020] [fcgid:warn] [pid 1222:tid 140545747322624] (32)Broken pipe: [client 2001:16b8:af3:9b00:857:2719:63cf:31f0:46204] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer: https://www.philosophies.de/wordpress/wp-admin/


    Könnt Ihr mir weiterhelfen?


    Vielen Dank und viele Grüße


    Bux