Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

Moin,

aufgrund der Fehler in php-fpm, vor allem das der Timeout nicht unendlich einstellbar ist, hat mich dazu bewogen mod_apache für meinen Ubuntu 18.04 einzusetzen. Mit erfolg, die Seite läuft nun ohne Timeouts gerade bei langen Datenbankoperationen.

Leider hat sich wohl ein Fehler durch liveconfig eingeschlichen den ich zwar nicht reproduzieren kann aber der in der error.log vermerkt ist

[Mon Sep 30 12:38:07.344059 2019] [php7:error] [pid 1285] [client 44.64.56.xx:36166] script '/usr/share/liveconfig/html/email.compose.php' not found or unable to stat
[Mon Sep 30 12:43:37.091285 2019] [php7:error] [pid 1236] [client 148.64.56.xx:33739] script '/usr/share/liveconfig/html/email.php' not found or unable to stat
[Mon Sep 30 13:39:08.600601 2019] [php7:error] [pid 1236] [client 148.64.56.xx:23436] script '/usr/share/liveconfig/html/start.php' not found or unable to stat
[Mon Sep 30 14:52:20.492367 2019] [php7:error] [pid 1264] [client 148.64.56.xx:35310] script '/usr/share/liveconfig/html/webdisk.php' not found or unable to stat
[Mon Sep 30 15:10:46.469588 2019] [php7:error] [pid 1078] [client 54.36.148.xx:47560] script '/usr/share/liveconfig/html/index.php' not found or unable to stat
[Mon Sep 30 15:57:08.857594 2019] [php7:error] [pid 9876] [client 148.64.xx.xx:20924] script '/usr/share/liveconfig/html/email.php' not found or unable to stat

Die PHP Datein entsprechen den Datein die eigentlich unter /va/www/webx/htdocs/ zu finden sind...Irgendwo hat sich da ein falscher Pfad eingeschlichen:

/usr/share/liveconfig/html/

Die Datein existieren natürlich unter diesem Pfad nicht nur in htdocs, bei PHP-FPM tritt der Fehler nicht auf.... kann mir da jemand helfen?

Guten Tag,

danke für den Hinweis, werde ich prüfen...Ja ich meine mod-php aber ich verwende ausschließlich dedizierte Server allein für meine Projekte.

Die timeouts passieren bei Datenbanken mit 900 Mrd Einträgen und deren Operationen nun mal, da kann man optimieren wie man will und es handelt sich auch um ein regelmäßig gepflegtes Script das schon fast 20 Jahre am Markt ist, keine Eigenentwicklung und auch die Hardware ist schon high end und völlig überdimensioniert für so ein kleines Script. Bei mod_php ist das alles unproblematisch nur bei FPM gibt es ständig gateway errors was wohl am mod_proxy selbst liegt, ich habe zumindest aktuell noch keine Lösung gefunden den Fehler gänzlich abzustellen, eventuell ist es aber auch nur ein bug.

Zitat

Lang-andauernde Operationen gehören nicht über den Apache, sondern in die CLI.

Gebe ich dir vollkommen recht bei mysql mache ich das auch so aber mein Dienstleistung ist ja genau das, Mailpostfächer anzubieten und da gibt es Postfächer mit großen Mengen an Daten die gelöscht werden müssen teilweise 100.000 und bei 900 Mrd Mail in SQL dauert das manchmal zu lange.

Zitat

Proxy?

mod_proxy_fcgi und dafür braucht es mod_proxy (ich hasse Abhängigkeiten) und dann brauche ich vermutlich noch proxy_http2 und proxy_http meinst ich soll mal was anderes verwenden? Fcgi habe ich noch bei Ubuntu 14.04. verwendet. Das stecken wieder so viele apache module drinnen die den Apache ausbremsen, das gefällt mir alles nicht wieder neue logs bei 1.500.000 requests am Tag

Also ist mod_php jetzt wirklich so schlecht? Das einzige was mich wirklich stört ist http2, das geht unter mod_php nicht und das ist mist

Zitat

Nobbi: Rein aus Interesse, Du speicherst 900.000.000.000 E-Mails und deren Rohdaten in einer MySQL (!) Datenbank? Warum macht man sowas?

Nein, die Datenbank hat nur die Verweise zu den Mails deren Daten auf dem Storage Server liegen, sonst wäre die Datenbank 21TB groß. Der Script Hersteller hat nun auch viele asynchrone Operationen eingeführt um das Löschen von Usern wenigstens erträglich und ohne Timeouts durchzuführen aber wenn ich z.b die tägliche Logfile durchsuchen will, Mails aus den Ordnern der User löschen oder User ihre Mails selbst löschen wollen dann muss das Script die 100.000 mails in der Datenbank finden und dann die Daten zusammen mit dem auf dem Storage befindlichen Daten zusammen löschen. Ich denke das es nicht sinnvoll ist jede Mail einzeln zu löschen gleichwohl die teilweise 400byte groß sind! Auch die Technik versagt hier immer mehr, der Storage und seine Suchzeiten sind auch unterirdisch und 21 TB SSD ist für einen kostenlosen werbefinanzierten Dienst 2019 eben auch nicht mal aus dem Ärmel geschüttelt.

Zitat von Mogwais

Klingt nach B1gmail. Wobei man sowas über Queue im Hintergrund machen sollte.

Jo korrekt, die Lösung hingegen verstehe ich nicht. Für die Mailzustellung und Versand gibt es ja bereits seit Jahren eine Warteschlange, hat ja jetzt mit Zustellung etc nicht zu tun, hier geht es ja um die Speicherung von langfristigen Daten bis hin zu 2008. Sicher wäre die Abarbeitung der Löschoperationen in einer Warteschlange sinnvoll aber ich wüsste nicht wie ich sowas gewährleisten kann.

Das problem hat sich übrigens von selbst geklärt. Heute Update/Upgrade gemacht und der Timeout ist weg

seit dem Update heute morgen scheint es keine Probleme mehr zu geben, kein Timeout, keine Fehlermeldung mehr, seltsam....alles gut plötzlich...ich hatte proxy_http und proxy_http2 deaktiviert, glaub zwar nicht das es daran lag aber vllt an dem Update und Upgrade von heute. Wegen dem BS war eigentlich der Gedankengang alle PHP Prozesse in einer Warteschleife oder cache zu halten bis diese abgearbeitet sind während im Vordergrund das Script weiter läuft, irgendwie so, Schnapsidee.

Bei Ubuntu 18.04 kein mpm_event unter mod_php und demzufolge auch kein http2, daher ist das mit FPM schon besser jetzt....auf jedenfall danke für die Hilfe Männers!