Beiträge von elektrowolf

Hallo Christiane,

vielen Dank für die Hinweise,

ich gehe davon aus, dass wir von der Subdomain kgv-stichkanal.womette.de sprechen.

Bei "Cookie-Hinweise" und "Anfahrt" habe ich im Browser (firefox esr) keine Fehlermeldungen und alles läuft zackig. Auch unter Android aufm Handy.

Nö, schon richtig, Joomla braucht kein PHP 8.3.9, aber möglicherweise hat der Server Probleme mit dem verfügbaren PHP 8.2.21.

Und immer wieder die Frage, wieso Error 503 nur in der Subdomain und niemals beim identischen Klon in der Domain?

Gruß elektrowolf

Heute morgen ist der Error 503 in der Subdomain wieder aufgetreten. War durch wiederholtes Einstellen von PHP 8.2.21 auf dem Server nicht zu beseitigen.

Erst das wiederholte Einstellen von 8.3.9 beseitigte letzendlich den Error 503.

CMS läuft jetzt mit dieser Einstellung weiter.

Abwarten ob es jetzt fehlerfrei bleibt.

Hallo Jan,

vielen Dank für den Hinweis.

Der Handler ist bei der Domain und allen aktiven Subdomains auf "FPM-Anwendung (Apache)" eingestellt und wurde in der Vergangenheit nicht verändert.

So, die ehemals vom Error 503 heimgesuchte und seit kurzem mit PHP 8.3.9 fehlerfreie Subdomain habe ich wieder auf das sonst allgemein verwendete PHP 8,2,21 umgestellt,

Wenn alles mit rechten Dingen zugeht, müsste auf der Subdomain der Error 503 über kurz oder lang wieder auftauchen.

Mal sehen.

Gruß elektrowolf

Ach, fast hätte ich vergessen, es zu erwähnen:

Seit einiger Zeit hatte ich in der Subdomäne im Verzeichnis /phpbb3 eine autarke PHPbb--Anwendung laufen. Diese sollte über eine Bridge an Joomla5 angebunden werden, dazu ist es aber nicht gekommen.

Jedes Mal, wenn die Webseite nebst Admin-Zugang durch Error 503 kurzzeitig oder dauerhaft blockiert wurde, konnte man die PHPbb.Seite fehlerfrei aufrufen.

Da diese derzeit nicht benötigt wird und um jede Rückwirkung auf den Error 503 bei Joomla auszuschließen, habe ich sie zwischenzeitlich gelöscht. Auch das hatte keinen Einfluss auf den Error 503 bei Joomla.

Daraus schließe ich bei Betrachtung des bisher insgesamt diskutierten Phänomens, dass dem Server irgendetwas an der Kombination Subdomäne/aktuelles Joomla 5/PHP 8.2.21 nicht gefällt.

Wie oben erwähnt, sollte man einige Tage abwarten, ob sich der Error 503 mit der PHP-Version 8.3.9 erledigt hat.

JoomlaWunder:

Wie weiter oben dargestellt, findet derzeit keine Umleitung auf den Klon statt. Das Original läuft ja jetzt noch.

Mit dem permanenten Error 503 auf dem Original meine ich, dass dieser Error stunden- bis tagelang anhielt und zuletzt nur durch neues Abspeichern der PHP-Version auf dem Server über das Kundenpanel vorübergehend aufgehoben werden konnte.

Aber nur vorübergehend, bis ich die PHP-Version (nur für die Subdomäne)) auf 8.3.9 statt 8.2.21 eingestellt habe. Damit läuft das Original bis jetzt noch ohne Error. Wird sich zeigen, ob das so bleibt.

Elwood:

Genau, vermute ich so langsam auch, dass es irgendwie an der Subdomäne liegt.

Allerdings tritt der Fehler erst neuerdings auf, obwohl ich Joomla 5 seit der Freigabe auf dieser Subdomäne und woanders auch verwende.

Vielleicht ein Zusammenhang mit der letzten Aktualisierung von Joomla?

Zum Zeitpunkt der Freigabe von Joomla 5 hatte ich 3 weitere Subdomänen zu Testzwecken damit am Laufen, immer ohne Error 503.

Nun denn, ich sollte vielleicht doch einmal abwarten, ob sich der Error 503 mit PHP 8.3.9 erledigt hat.

Gruß elektrowolf

Beschränken wir uns doch der Einfachheit halber auf die vom permanenten Error 503 betroffene Subdomäne kgv-stichkanal.womette.de, auf die niemals umgeleitet wurde.

Und auf die vom Error 503 stets freie Webseite unter womette.de/jm4, auf die ich vor über 15 Jahren zunächst auf /jm25 und später auf jm4 aus heute nicht mehr relevanten Gründen eine Weiterleitung mit einer index.html von womette.de aus vorgenommen habe. Nix mit einer Umleitung über Verwendung von .htaccess oder index.php oder sonst was.

Somit entsprechen diese beiden Webseiten der reinen Lehre und man kann sich ganz auf den Error 503 konzentrieren.

Gruß elektrowolf

Hallo Joomlawunder,

die Sache mit den 2 sich abwechselnden Instanzen habe ich auf Nachfrage von Elwood näher ausgeführt, sie hat mit dem schon vorher aufgetretenen und von mir nachgefragten dauerhaften Error 503 offensichtlich nichts zu tun.

Die Umleitung auf eine andere Instanz war lediglich eine gelungene Notlösung, die weitere Erreichbarkeit der Webseite unter der originären Webadresse sicher zu stellen und muss hier nicht wirklich weiter diskutiert werden.

In der Vergangenheit habe ich bei mehreren Providern Verschiebungen und Umleitungen von mehreren Webseiten vorgenommen und bin mir der in diesem Zusammenhang auftretenden Fehlerquellen durchaus bewusst.

Meine Frage wäre somit nach wie vor und nach den weiter oben bereitgestellten Angaben, wo der Fehler zu suchen ist, auf dem Server oder in einer der Joomla-Webseiten.

Verwirrend ist das Ganze nur insoweit, als dieser Fehler ausschließlich in der Subdomain kgv-stichkanal.womette.de auftritt, nicht aber in dem davon abgeleiteten Klon unter womette.de/kgv-stichkanal oder der völlig separaten Webseite unter womette.de(jm4.

Es sind alles aktuelle Joomla5-Anwendungen und hatten zum Vergleichszeitpunkt alle die PHP-Version 8.2.21.

Wenn man vermutet, der Fehler, der zum dauerhaften Error 503 führt, ist in der Subdomain kgv-stichkanal.womette.de zu suchen, wieso ist dann der Klon unter womette.de/kgv-stichkanal, bei dem nur gegenüber dem Original die Pfade in der configuration.php angepasst wurden, permanent fehlerfrei?

Gruß elektrowolf

Hallo Elwood,

hast schon Recht, dieselbe Datenbank sollte man nicht für 2 Instanzen verwenden. Hier gelobe ich Besserung oder wie ich im Berufsleben bei Beanstandungen immer geantwortet habe: "Wird zukünftig beachtet".

Aber es hat als schnelle Notlösung wunderbar funktioniert immer unter der Voraussetzung, dass ein Backup der bisher verwendeten Instanz unmittelbar vor Verwendung auf den Klon überspielt wurde und umgekehrt. Ich glaube nicht, dass die Datenbank das überhaupt "bemerkt" hat, jedenfalls gab es nie eine diesbezügliche Fehlermeldung. Alles auch unter der Voraussetzung, das niemals gleichzeitig auf beide Instanzen zugegriffen wurde.

Und der dauerhafte Error 503 trat schon vor dieser Aktion beim Original auf, aber bis dato niemals beim Klon.

Ich kann mich erinnern, dass ich bei Strato bequem das Root-Verzeichnis ändern konnte, so dass es keiner Umleitung durch mich bedurfte.. Bei meinem Provider und bei mehreren Webseiten sieht das schon anders aus. Der User soll unverändert die gleiche Webadresse verwenden, egal, was ich für Änderungen bei den Verzeichnissen vornehme.

So stelle ich der Datei index.php des Originals z.B. den nachfolgenden Code voran:

<?php
header("Location: https://www.womette.de/kgv-stichkanal/index.php");
exit();
?>

Gruß elektrowolf

Bei der Kopie muss ich die configuration.php nur einmal ändern, wenn ich die Kopie in Betrieb nehme. Beim Original ändere ich dann index.php und. html, in dem ich dort eine Umleitung einfüge.

Orginal und Kope arbeiten übrigens mit der gleichen Datenbank, aber niemals gleichzeitig.

Gruß elektrowolf

Das ist richtig. Beim Umschalten auf die Kopie muss ich aber einige Pfade ändern.

Hallo Elwood,

im Userpanel kann man bei der Subdomain die PHP-Version des Servers auswählen und speichern. Ausgewählt war zunächst 8.2.21. Hab ich erneut abgespeichert. Hat vorübergehend geholfen. Zur Zeit habe ich 8.3.9 gewählt und abgespeichert.. Bis jetzt kein Error. Was mich irritiert, ist, dass es bei der identischen Kopie (ebenfalls 8.2.21) niemals einen Error gegeben hat. Die configuration.php muss natürlich beim Wechsel immer angepasst werden.

Hallo,

habe 2 Webseiten mit aktuellem Joomla 5 laufen, bisher störungsfrei..

Eine der Webseiten (https://kgv-stichkanal.womette.de/index.php) zeigte in den letzten Wochen beim Aufruf die Fehlermeldung "Error 503 Service not available", auch auf dem Admin-Eingang. Nach einigen Minuten bis Stunden war die Seite wieder zugänglich.

Beim Abspeichern eines geänderten Beitrags trat der Error 503 wieder auf und blockierte jetzt dauerhaft Webseite und Admin-Eingang.

Der Provider (webspace-verkauf.de) wurde nach dem Grund befragt, äußerte sich dazu aber nicht und empfahl, im Kundenpanel die PHP-Version erneut zu setzen. Das funktionierte vorübergehend tatsächlich.

Während der Blockade der Webseite habe ich diese zwecks Erreichbarkeit auf eine identische Kopie (https://www.womette.de/kgv-stichkanal/) mittels index.php und .html umgeleitet, wo sie störungsfrei weiter funktionierte.

Bei der letzten Blockade der Webseite habe ich der Abwechslung halber die PHP-Version auf 8.3.9 (vorher 8.2.21) gesetzt, was bis jetzt funktioniert.

Eine weitere Webseite auf dem gleichen Server (https://womette.de/jm4/) mit aktuellem Joomla5 funktioniert seit eh und je ohne Störung.

Alles schön und gut, aber diese semi-empirischen Methoden gehen mir auf den Geist und ich hätte gerne den Grund für die wiederholten Blockaden gewusst un dementsprechend abgestellt.

Kann mir jemand weiterhelfen?

So, nun noch einmal zum Problem mit der Warnmeldung auf allen Seiten bei Verwendung des DWD-Wettermoduls in Joomla 4 mit Template Cassiopeia.

Unabhängig von der Anzahl der Wettermodul-Instanzen ist das Phänomen zuletzt ca. alle 7 Tage aufgetreten. Dabei hatte ist stets eine Instanz in der linken oder rechten Seitenspalte laufen. Man will ja beim Aufruf der Webseite schnell einen Überblick über die aktuelle Wettersituation haben.

Das Wettermodul wird somit bei jedem Aufruf der Startseite und der anderen Seiten neu geladen, was ihm aber offensichtlich nicht gefällt und nach einiger Zeit wegen der weiter oben dargestellten Dateikollision zuverlässig die nervende Warnmeldung auslöst.

Thomas Hunziker von bakual.net schlägt vor, den Joomla-Cache zu aktivieren, um das Problem zumindest abzumildern.

Kann man machen, aber meines Wissens ist diese Aktivierung dann für die gesamte Webseite, was ich allerdings nicht möchte.

Die in einem vorhergehenden Beitrag erwähnte Methode, die .nfs-Datei mit einer PHP-Codesequenz oder dem Task-Scheduler zu eliminieren, ist zwar hocheffizient, mir aber momentan noch zu rustikal.

Statt des DWD-Wettermoduls habe ich in einer Seitenspalte jetzt ein Navigationsmenü untergebracht, welches neben wetterrelevanten URLs auch den Link zu einem Beitrag enthält, in dem mittels {loadposition meineposition_w} das DWD-Wettermodul somit nur bei Bedarf und nicht jedes Mal bei Aufruf einer Seite geladen wird.

Bisher keine Warnmeldung mehr. Wollen hoffen, dass es so bleibt.

Wobei es ALGOL60, wie der Name schon sagt, seit ca. 1960 gibt und es z.B. teilweise an Ingenieurschulen bis in die 80er Jahre verwendet wurde.

firstlady:

Christiane, vielen Dank für den Hinweis auf den Task-Scheduler. Scheint interessant zu sein und ich werde ihn mir demnächst mal reinziehen.

"Dann wird es Zeit, dass du dich wieder fit machst."

Locker dahin gesagt. Habe ich mir auch schon öfters gedacht.

Aber, Christiane, ich habe schon Anwendungen programmiert, als Du vermutlich noch nicht auf dieser Welt warst und die Liste der Prorammiersprachen von Studium und Beruf beginnt bei ALGOL60 und endet bei Delphi und PHP. Die der Betriebssysteme, an denen ich mich vergangen habe, beginnt bei CP/M und endet heute bei Debian Linux.

Wollte ich mich nur in den heute davon noch lebenden Betriebsystemen und Programmiersprachen fit halten, hätte ich bestimmt keine Zeit mehr für meine Enkelkinder :).

Gruß

Wolf

So, was soll ich sagen, nach 7 Tagen war das Phänomen wieder da. Auch mit nur einer Instanz.

Vielleicht gibt es ja analog zur dunklen Materie auch dunkle Instanzen, wer weiß, wer weiß

Vorsichtshalber habe ich das DWD-Wettermodul komplett gelöscht und dann neu Installiert. Jetzt müsste sauber nur noch eine Instanz vorhanden sein, Wenn man mal von dunklen Instanzen im DWD-Modul absieht.

Mit Thomas Hunziker von bakual. net stimme ich überein, dass die Warnmeldung nebst .nfs-Datei eigentlich nur duch ein Fehlerereignis in einer sog. "race-condition" auftreten kann, wenn zwei oder mehrere Instanzen um den löschenden bzw. schreibenden Zugriff auf eine Datei wetteifern.

Wie dem auch sei, falls der Fehler wieder auftritt, werde ich das Problem lösen mit einer Codesequenz, die pro Tag (oder Stunde) einmal nachschaut, ob in dem besagten Verzeichnis eine .nfs-Datei vorhanden ist, und falls ja, diese löscht und vielleicht auch darüber Buch führt. Nicht sonderlich elegant, aber äußerst wirksam.

Ich hab ewig kein PHP mehr programmiert und bin alt und gebrechlich . Hat Jemand zufällig etwas Passendes zur Hand?

Danke und Grüße

Wolf

Vielen Dank für den Hinweis, Elwood.

Werde demnächst eine Anfrage starten. Möchte allerdings noch ein bis zwei Zyklen abwarten, vielleicht habe ich dann schon einen Beweis für meine Vermutung.

Gruß Wolf

So, und nun ist die Warnung nach ca. 10 Tagen wieder aufgetaucht.

Der Inhalt der .nfs-Datei ist identisch mit der im gleichen Verzeichnis befindlichen Datei MOSMIX_L_2022031021_N9030.kml. Sie enthält u. a. 250 Stundenschritte für die Wettervorhersage.

Vermutlich wird nach Ablauf der 250 Stunden die Datei neu geladen und dann gibt es wohl den Ärger, der zu der besagten Warnung führt. Eigentlich ist mir jetzt auch völlig klar, warum.

Leider habe ich vergessen, zu erwähnen, dass ich das DWD-Wettermodul in 2 Instanzen gefahren habe. Das ist ja bei anderen Modulen (z.B. Navigationsmenüs) mit meistens mehr Instanzen an der Tagesordnung, funktioniert problemlos und somit nicht eine Erwähnung wert.

Offensichtlich geht das aber nicht mit dem DWD-Wettermodul.

Wie es aussieht, greifen beide Instanzen auf die eine Datei im Verzeichnis tmp/mod_dwd_wettermodul_kmz nach Ablauf der o.g. Stunden schreibend bzw. löschend zu, was regelmäßig zu Fehlern und der besagten Warnmeldung führt.

Habe jetzt nur noch eine Instanz des Wettermoduls laufen und gehe davon aus, dass die Warnung nicht mehr erfolgt. Hoffentlich.

Habe die Vorgängerversion ohne Auffälligkeiten seit Sommer 2021 unter J3 betrieben. Immer vorausgesetzt, dass es am DWD-Wettermodul liegt, ging es dann mit den Warnmeldungen im Dezember unter J4 los. Die vor 3 Wochen installierte aktuelle Version 6.0 hat daran nichts geändert. Was mich aber überfordert, ist die Tatsache, dass die Warnmeldung beim aktiven T4-Template "schön ordentlich" auf der Wettermodulseite auftaucht, beim aktiven Cassiopeia-Template aber auf jeder Seite. Habe jetzt wieder Cassiopeia laufen und mal sehen, wo man beim nächsten Mal die .nfs-Datei(en) finden kann.

Gruß Wolf

Erst einmal vielen Dank für die schnellen Antworten. Das ging ja ruck-zuck. Hat man auch nicht alle Tage.

firstlady: Mit Zeilenumbrüchen sind sicherlich Absätze gemeint.

Die heutigen Editoren und sonstigen Programme zur Textdarstellung machen Zeilenumbrüche meistens automatisch, damit der Text schön in das Fenster passt. Will ich den Zeilenumbruch mit <enter> erzwingen, gibt das in vielen Editoren einen Absatz, so beim TinyMCE, allerdings nicht hier und auch nicht bei meinem Gnome-Tetxteditor. Vermutlich Einstellungssache.

Wie dem auch sei, in der Tat erhöht ein nicht zu sparsamer Gebrauch von Absätzen deutlich die Lesbarkeit.

Meine Webseite wird in der Regel recht aktuell gehalten. Sobald ein Update vorgeschlagen wird, installiere ich es zeitnah. Was das DWD-Wettermodul betrifft, meine ich es vor wenigen Wochen ebenfalls aktualisiert zu haben.

Filezilla habe ich die Verzeichnisse der Webseite nach einer .nfs0-Datei durchsuchen lassen.

Hat endlos lange gedauert, ganz zum Schluss wurde die Datei gefunden im Verzeichnis

/jm406/tmp/mod_dwd_wettermodul_kmz.

In diesem Verzeichnis werden offensichtlich geografische Daten in .kml-Dateien gespeichert. Passt genau, bei aktivem T4-Template gab es ja nur beim DWD-Wettermodul die Warnmeldung.

Dummerweise habe ich im Übereifer die .nfs-Datei vom Server gelöscht, ohne sie vorher herunterzuladen. So konnte ich nicht nachsehen, ob sie irgendwelche brauchbaren Informationen enthält. Jedenfalls ist jetzt die Fehlermeldung verschwunden, und zwar auch in Cassiopeia.

Bezüglich weiterer Untersuchungen werde ich dann wohl warten müssen, bis das Phänomen erneut auftritt. Ich werde beizeiten berichten.

Aber auch so bin ich schon mal einen Schritt weiter.

Vielen Dank für die Hilfe!