Ich bin bei Timmehosting, soweit ich weiss sind das 64bit systeme.
Hallo,
das Hostsystem ist 64 Bit, Output von uname -a:
Linux web09.in.easyname.com 4.9.0-0.bpo.4-amd64 #3 SMP Debian 4.9.65-3+deb9u1~bpo8+2 (2018-01-05) x86_64 GNU/Linux
Auch der Kundendienst von easyname.at hat mir nochmals bestätigt, dass das Hostsystem ein 64Bit System ist.
Ich habe jetzt trotzdem mal die Funtkion dechex() hinzugefügt.
Deaktivieren von ATSD hat also nicht geholfen?
Das deinstallieren von ATSD hat leider nicht geholfen, mir ist es zwar nicht mehr selbst aufgefallen aber in der access.log konnte ich oft genug sehen, dass 404 Errors bei den Seiten wie /aktionen kam.
Seit dem hinzufügen der dechex Funktion wie von Moritz beschrieben derzeit keine 404 Fehler mehr. Hoffentlich bleibt das so.
access.log damit meinst du das Script von lappies? In den herkömmlichen Logfiles wird bei uns nämlich nichts angezeigt. Wir haben auch Timme mit 64bit, trotzdem heute Morgen wieder das Problem. Mit dechex Funktion weiter Ruhe? Muss man da einfach in die zwei Dateien den Code einfügen?
Hallo,
leider funktioniert das auch nicht mit der dechex Funktion 
Nein script ist es keines, ein einfacher Befehl in Linux, damit ich die 404 Errors auslesen kann:
grep " 404 " access.log
Kannst dir aber auch runterladen und dann mit Notepad++ öffnen etc.
Wir brauchen ganz dringend eine Lösung für dieses Problem!
Danke, ja wirklich. Ich fasse mal zusammen:
Problem mit dem Aufrufen von Kategorien über den Seo-Link. Nach dem Aufruf einer betroffenen Kategorie kommt die Startseite (also 404). Der SEO Link in der Tabelle s_core_rewrite_urls ist zum Zeitpunkt des Auftretens mit korrektem Systemlink vorhanden. Der Aufruf des Systemlinks klappt auch ohne Fehler. Leert man den Cache geht alles wieder für ein paar Stunden, u.U. auch Tage. Das Problem betrifft immer andere Kategorien, wechselt also munter, mal Hauptkategorien, mal Unterkategorien,…
- Problem seit 5.3, Update auf 5.4 bringt keine Besserung. Wir sind übrigens direkt mit der 5er Version vorletztes Jahr gestartet.
- keine gemeinsamen Plugins bei betroffenen (bekannten) Shops, darunter auch ein Shop mit nur zwei Plugins (Wawi connector, Gallerie Plugin). DAS Plugin oder Verdacht ein SEO-Plugin trifft wohl nicht zu. Deinstallieren vom Plugin ATSD brachte auch nichts (hatten immerhin drei Shops)
- alle Kategorien einzeln nochmal speichern (also nur speichern, nicht neu anlegen), keine Lösung
- Drei Shops sind bei Timmehosting. Timme hat dann gestern bei uns nginx aktualisiert und die Datenbankeinstellungen angepasst. Außerdem den Opcache etwas größer eingestellt und einen neuen Cronjob angelegt (seit Shopware 5.1 empfiehlt Shopware einen etwas anderen Aufruf des Cronjobs). Es handelt sich um ein 64bit System. Problem besteht weiterhin.
- Funktion dechex() (Vorschlag von Admin Moritz Naczenski s.o.) leider auch keine Lösung - ???
Ich habe das ganze beobachtet, bisher ist es noch nicht wieder aufgetreten. Ich habe bisher nichts geändert, trete sowieso immer sporadisch auf.
Mein Shop habe ich anfang 2017 auf Shopware umgestellt, damals aktuellste Version.
@kci
mein script ist auch nichts anderes als grex befehl.
Du kannst dich mit putty auf dein Timmeserver einloggen, einfach ein Shell benutzer anlegen in ISPConfig wenn nicht schon getan, und dann kannst du den befehl auch direkt absetzten. Ich habe den befehl in ein script gepackt, so muss ich es nicht jedesmal eintippen. Wir lesen nicht Shopwarelogs aus sondern die vom Webserver, liegt bei mir unter /log/access.log
Befehl sieht wie folgt aus
cat /log/access.log | grep " 404"
Ich filter aber so paar andere meldung(leichen) auch weg, z.B. alte Shopurl die immer noch gecralt werden, mit grep -v macht man das, sieht dann so aus
cat /log/access.log | grep " 404" | grep -v "/shop" | grep -v "/forum"
Bei Timme wird die access.logs jeden Tag rotiert, du liest also nur den aktuellen Tag dort aus. Gesterns Logfiles liest sich bei mir wie folgt aus
cat /log/20180327-access.log | grep " 404"
Und vorgesterns Logfile ist komprimiert und liest sich wie folgt aus
zcat /log/20180326-access.log.gz | grep " 404"
@lappies welche Version läuft bei dir?
5.4.1
Der Fehler ist bei mir seit 08 Uhr schon dauerhaft, habe jetzt mal die PHP Version von 7.0 auf 5.6 gestellt, welche PHP Versionen habt ihr im Einsatz?
7.0.9
Heute kein fehler vorhanden.
Kannst du es vielleicht an ei Uhrzeit festmachen? Wann laufen welche cronjobs…
5.6.30, ich habe jetzt alle zwei Stunden den Cronjob HTTP Cache löschen eingestellt.
5.6.30, ich habe jetzt alle zwei Stunden den Cronjob HTTP Cache löschen eingestellt.
…also dieser Standard-Cronjob „HTTP Cache löschen“ behebt das Problem nicht analog zu „Shopcache leeren“ im Backend.
Was heißt denn seit 8Uhr dauerhaft? Ohne Cache löschen oder trotzdem?
Ohne Cache löschen, normal hat es immer nach einer kurzen Zeit wieder funktioniert. Aber das waren dann mind. 4 Stunden, wo ich dauerhaft einen 404 error bekommen habe. Das wäre der optimale Zeitpunkt gewesen, dass der Support von Shopware es mal selbst sehen kann, aber stattdessen bekomme ich immer die Antwort „Ich kann das nicht reproduzieren, bei mir kommt kein 404 Error“ 
Diese Beobachtung haben wir noch nicht gemacht, dass es irgendwann wieder ging, da wir regelmäßig kontrollieren und löschen. Wir haben es schon 2x von Shopware ansehen lassen, beide Mitarbeiter konnten unabhängig voneinander
“das Verhalten bis zum Leeren des Caches auch nachvollziehen. Bei diesem Verhalten handelt es sich allerdings nicht um ein allgemeines unerwünschtes Verhalten. Allerdings müsste man hier zur weiteren Evaluierung des Verhaltens über einen längeren Zeitraum alle Drittanbieter Plugins deaktivieren und das Verhalten beobachten. Wenn Ihnen dieser Vorgang im Live-System nicht recht ist, sollten Sie eine aktuelle Testumgebung in einem Unterordner innerhalb Ihrer Shopware Installation erstellen, indem Sie diese Überprüfung vornehmen können.”
Das Problem ist, das wir inzwischen 48 Plugins installiert haben. In der Testumgebung konnte das Problem noch nicht gesichtet werden. Aber diese wird ja auch nicht weiter genutzt, also weder im Backend noch im Frontend. Nach jedem Deaktiveren eines Plugins wird der Cache gelöscht und dann würde es so oder so wieder funktionieren. D.h. der ganze Prozess würde ewig dauern und je nach Plugin würde der Shop in seiner Funktionalität stark eingeschränkt sein. Manche Plugins wie Pickware oder auch Zahlarten können ja auf keinen Fall deaktiviert werden.
Ehrlich gesagt verstehe ich die vorgehnsweise von die Shopware Mitarbeiter nicht. Fehlerdiagnose führt man anders aus als alles zu deaktivieren und zu beobachten.
Ich war sehr lange linux systemadministrator und kenne mich denke da ein bischen aus was fehlerdiagnosen angeht.
Leider kenne ich mich nicht so gut mit php, html etc. prorammierung aus um mich in die genaue abläufe in Shopware einzuarbeiten um zu verstehen was passiert wann und wo und warum. Ich kenne mich viel mehr mit das system linux selbst und seine dienste wie webserver, mailserver, datenbankserver etc. aus.
Wenn ein fehler auftritt, muss irgend etwas nicht funktionieren, am besten ist auch ein logeintrag irgendwo. Fehlt ein Logeintrag muss man halt anders das problem einkreisen.
Man schaut sich genau den ablauf der aufruf an. Wir rufen eine Seite auf. Also ist zu prufen welcher script wird aufgerufen und welcher befehle,queries etc. innerhalb diese script ausgeführt wird um ans ziel zu kommen. Shopware sollte doch ihre eigene System kenne um zu wissen was passiert wann und wo. Jetzt muss man doch rausfinden an welcher stelle hackt es bei diesen aufruf. Hat man die stelle gefunden muss man schauen warum hackt es hier, warum schlägt es fehlt und weiter in diese richtung diagnosen durchführen. Ist es ein temp. zugriffsproblem, fehlt etwas temp. irgendwo, etc.
Dazu steht die entwicklere auch viele debug möglichkeiten zu verfügung, php debug und logging auf höchste stufe stellen, fehlerausgabe im frontend, strace auf der console und da gibt es sicherlich noch viel viel mehr php debug möglichkeiten die ich nicht kenne.
Einfach zu sagen kann ich nicht reproduzieren und deaktiviere mal alles andere ist aus meine sicht einfach aussagen um sich um denn fehlerdiagnose zu drucken. Der fehler ist bei einige kunden mit unterschiedliche Plugins vorhanden und kann auch live angesehen werden, da kann man dann auch fehlerdiagnosen durchführen.
Momentan wissen wir ja noch garnicht warum die 404 kommen, cache problem, zugriff problem, zuordnungsproblem etc…
Das sporadische fehler immer schwer zu beheben ist kenne ich ja nur zu gute. Wenn der fehler aber gerade vorhanden ist und man dieses wiederhollt hintereinander reproduzieren kann, kann man auch genaue fehlerdiagnose durchführen.
Was macht Shopware wenn du jetzt ein Plugin ausfindich gemacht hast. Da muss man doch auch fehlerdiagnosen durchführen.
Ich habe mir jetzt ein script geschrieben. Script überprüft in 5min takt per curl alle vorhandene URLs, bei mir nur 44 Stück.Wenn ein URL ein 404 zurück gibt, wird ein log geschrieben und ich bekomme ebenfalls ein mail mit besagten URL.
So bekomme ich jetzt alle 404 mit und auch wann die ±5min enstanden sind und ob die auch von selber wieder weg gehen oder nur nach cache leeren per hand oder cron. Mal schauen was dabei raus kommt. Script läuft auf ein externe Linuxserver wo ich vollen zugriff drauf haben, bei Timme habe ich nur begrenzen zugriff.
@kci und Grex
Auf wünsch kann ich eure Seiten auch vorübergehend überwachen und euch Emails zukommen lassen wenn der Fehler auftritt. Dazu brauche ich nur die zu überwachenden URLs und eine Emailadresse wohinn die mails verschickt werden soll und im welchen abstand der check laufen soll. Bei interesse bitte Daten per PM mitteilen. URLs findet man am einfachsten in der sitemap unter domain.de/sitemap.xml
@lappies vielen Dank für dein Angebot, aber ich habe einfach die access.log auf Dauerüberwachen gefiltert auf 404 (mit less o.a. mit tail -f möglich)
Ich bin gerade beim Debuggen, Problem: Es funktioniert von selbst wieder nach einiger Zeit, war heute mitten drinnen, wo es dann funktioniert hat.
Auf was ich aber gekommen bin ist, in der shopware.php ganz am Schluss:
$kernel->handle($request)->send();
In der Datei unter engine/Shopware/Kernel.php hätte ich bei der Funktion handle() mal den Request ausgegeben, bzw. ein echo „Hello“; exit;
Fakt: Bei der funktionierenden Seite zeigt er mir nun „Hello“ an und bricht ab, bei der nicht funktionierenden Seite zeigt er mir die gerenderte Seite (also mit Layout etc.) an, ohne den Output „Hello“. Bedeutet er geht nicht nicht in die Funktion handle der Klasse Kernel rein.
Ich vermute der Fehler liegt hier:
$request = Request::createFromGlobals();
Bevor ich weitermachen konnte, hat dann auf einmal die Seite wieder funktioniert, ohne Cache leeren etc.
Auch in den Logfiles hätte ich gecheckt, was aufgerufen wurde, damit wieder alles funktioniert. Laut access.log nichts!, gibt es eine Cronjob History bei Shopware? - Aber das müsste ja auch in der access.log drinnen stehen, oder nicht?
Anfangs lief mein Verdacht beim SSL, das hab ich ja auch aktiviert beim Update, aber auch ohne SSL tritt der Fehler bei mir nun auf. Mir ist folgendes im Request aufgefallen zwischen einer funktionierenden und einer nicht funktionierenden Seite:
Bei der funktionierenden Seite: SSL_SESSION_RESUMED => Resumed
Bei der nicht funktionierenden Seite: SSL_SESSION_RESUMED => Intial
Bevor ich das aber reproduzieren konnte, hat das aber wieder alles funktioniert, Status war bei beiden Resumed und ging auch in die hanlde Funktion der Kernel Funktion rein.
Was ich euch noch fragen wollte, habt ihr SSL aktiviert, und wer ist der Aussteller des Zertifikats? (Letsencrypt,…)