Session-Abstürze seit dem Update auf 91.0ESR

  • Firefox-Version
    91.0ESR
    Betriebssystem
    Ubuntu

    Hallo zusammen,

    ich hoffe, hier könnte jemand eine Idee haben, woher der Fehler kommen könnte. Danke im Voraus fürs Lesen :)

    In unserem Unternehmen setzen wir seit Jahren auf die FF-ESR-Version. Momentan läuft bei uns produktiv noch die 78.15.0esr , welche wir aus offensichtlichen Gründen dringend updaten möchten. Nun haben uns jedoch unsere Tester, die gerade mit 91.0esr arbeiten, Fehler in mehreren In-Browser-Anwendungen berichtet, z.B. werden sie nach kurzer Bildschirmsperrzeit abgemeldet, oder Anwendungen melden einen Timeout.

    Da das Update rechner- und nicht user-bezogen durchgeführt wurde, arbeiten die selben User z.B. im Home Office noch mit der alten Version, wo die Fehler nicht auftreten. Auch die Kollegen, welche das Update noch gar nicht haben, arbeiten ohne Einschränkungen. Deshalb können wir mit sehr hoher Wahrscheinlichkeit den Faktor User(profil) und allgemeine Netzwerk-Einstellungen ausschließen.

    Wir haben inzwischen die Differenzen in about:config der beiden Versionen akribisch verglichen, konnten jedoch bisher nichts kritisches finden, was zu den Fehlern führen könnte.

    Bisher war mein Verdacht, dass es mit dem Cookie-/Cache-Handling bzw. den HTTP-Headern im Cache zu tun haben könnte. Diverse Anpassungen in diese Richtung haben bisher leider nicht gefruchtet.

    Wenn jemanden noch irgendwas einfällt, wo wir noch schauen könnten, wäre ich super dankbar!

    Falls irgendwelche Systeminformationen benötigt werden, stelle ich diese gern zur Verfügung.

    Danke und Gruß!

  • Hallo,

    da es um ein Problem auf einer bestimmten Seite geht, wird es sehr schwer für jemand Dritten, dazu etwas zu sagen, ohne ein reprozierbares Test-Szenario zu erhalten. Ohne ein Problem zu sehen, kann man diesem schließlich nicht auf den Grund gehen, zumal die Problembeschreibung auch extrem unspezifisch und allgemein ist.

    Hallo Sören,

    vielen Dank für deine Antwort!Das ist leider nicht eine einzige Seite, sondern mehrere. Lässt man beim Provozieren der Fehler die Konsole mitlaufen, bringt jede Seite auch was eigenes als Hinweis. Der (vermutlich) Einzige gemeinsame Nenner ist, wie gesagt, dass es irgendwie was mit

    Cookie-/Cache-Handling zu tun hat, ich konnte aber in den Release Notes oder in den Configs keine gravierende Änderung in diese Richtung feststellen.

    Dass es schwierig ist, den Fehler zu erkennen, ohne ihn zu sehen ist richtig. Ich würde gerne mehr Infos zur Verfügung stellen, weiß aber nicht so recht, was hier überhaupt relevant wäre.


    Ich hatte halt die Hoffnung, dass vielleicht irgendjemand mal was Ähnliches hatte.

  • Ich würde gerne mehr Infos zur Verfügung stellen, weiß aber nicht so recht, was hier überhaupt relevant wäre.

    Fange doch mal mit den Fehlerhinweisen an. Stelle die hier ein. Vielleicht lassen sich die Gemeinsamkeiten herausarbeiten.

    Übersetzer für Obersorbisch und Niedersorbisch auf pontoon.mozilla.org u.a. für Firefox, Firefox für Android, Firefox für iOS, Firefox Klar/Focus für iOS und Android, Thunderbird, Pootle, Django, LibreOffice, LibreOffice Onlinehilfe, WordPress

  • Ich würde gerne mehr Infos zur Verfügung stellen, weiß aber nicht so recht, was hier überhaupt relevant wäre.

    z.B einen Link zu einer Seite, auf der der beschriebene Fehler auftritt???

    Im Prinzip jede Seite, die mit RECaptcha arbeitet, z.B. Anmeldung bei https://www.meistertask.com/ oder https://zoom.us/

    Ist mir vorhin beim Registrieren hier im Forum ebenfalls passiert.

    Da Erscheint die Meldung, dass keine Verbindung zum Dienst aufgebaut werden konnte; erst nach dem Löschen von Cache/Cookies wird der Dienst geladen.

    Vor allem sind aber interne Seiten betroffen, Fremdsoftware die bei uns In-House gehostet wird (Produkte von USU, z.B). Kann ich verständlicherweise nicht verlinken :)

    S. Screenshot für Meldungen, die Firefox On-Board-Dev-Tools beim Fehler ausspuckt.

  • Ein Kompatibilitätsproblem von reCAPTCHA mit Firefox gibt es definitiv keines. Die Ursache dafür muss also in jedem Fall bei dir liegen - sei es in der Firefox-Konfiguration, im Firefox-Profil oder im Netzwerk.

    Wie sieht es denn imt Fehlerbehebungsmodus aus?

    Probleme analysieren im Fehlerbehebungsmodus von Firefox | Hilfe zu Firefox

    Wird ein Proxy oder VPN genutzt? Firewall? Sonstige Sicherheits-Software?

  • Ein Kompatibilitätsproblem von reCAPTCHA mit Firefox gibt es definitiv keines. Die Ursache dafür muss also in jedem Fall bei dir liegen - sei es in der Firefox-Konfiguration, im Firefox-Profil oder im Netzwerk.

    Wie sieht es denn imt Fehlerbehebungsmodus aus?

    https://support.mozilla.org/de/kb/probleme…gsmodus-firefox

    Wird ein Proxy oder VPN genutzt? Firewall? Sonstige Sicherheits-Software?

    Davon bin ich auch ausgegangen :) Leider kommt es im Fehlerbehebungsmodus auch so; mit einem frischen Profil ebenfalls das gleiche Verhalten.

    Proxy+Firewall sind vorhanden. Auf der Firewall haben wir aber schon testweise sämtliche white-list-Einträge für recaptcha ausprobiert, mit dem gleichen Ergebnis: Aufruf klappt erst nach einem Cache-Flush im Browser.

    Firewall ist in dem Sinne auch eher unwahrscheinlich da unsere in-house anwendungen ja nicht davon betroffen sind.

  • Ich finde die Firewall als Ursache ganz und gar nicht unwahrscheinlich in Anbetracht der Tatsache, dass hier eine Verbindung blockiert wird, die unter normalen Umständen einwandfrei funktioniert. Und selbst wenn es nur dazu ist, um, die Firewall wirklich ausschließen zu können, bitte teste einmal ohne sämtliche Maßnahmen, welche den Netzwerkverkehr beeinflussen können.

  • Ich finde die Firewall als Ursache ganz und gar nicht unwahrscheinlich in Anbetracht der Tatsache, dass hier eine Verbindung blockiert wird, die unter normalen Umständen einwandfrei funktioniert. Und selbst wenn es nur dazu ist, um, die Firewall wirklich ausschließen zu können, bitte teste einmal ohne sämtliche Maßnahmen, welche den Netzwerkverkehr beeinflussen können.

    Kurzer Zwischenstand zu dem Thema: die zwei Symptome haben nichts miteinander zu tun:

    1) der reCAPTCHA-Fehler liegt tatsächlich an der Firewall

    2) das andere Problem, nämlich die Session-Abstürze und Time-Outs bei den In-Browser-Anwendungen, hat einen Anderen Hintergrund.

    Nachdem der FF-Prozess mit strace und tcpdump überwacht wurde, konnte ich feststellen, dass ab dem Zeitpunkt der Bildschirm-Sperre Firefox einfach jegliche Netzwerk-Kommunikation kappt.

    Testkonstellation war die folgende:

    - ein Rechner, auf dem alle Programme/Prozesse möglichst beendet sind;

    - offen nur FF mit einem Tab, indem die Anwendung, die ins Timeout läuft.

    Am tcpdump war zu erkennen, dass der Rechner keine Pakete mehr zu dem Server der Anwendung rausschickt, sobald der Bildschirm gesperrt wird. Einzige Kommunikation, die noch lief, war der NFS-Server, LDAP Dienst und Anfragen an den Default Gateway.

    Strace hat ergeben, dass die Kinderprozesse sich nicht zu den lokalen TCP-Sockets verbinden können. Der Hauptprozess vom Firefox verabschiedet sich gänzlich und meldet sich erst wieder, wenn der Rechner entsperrt wird.

    Bei Firefox 87.09b (letzte Version, wo wir noch keine Probleme haben) ist dieses Verhalten nicht zu beobachten, da ist der Hauptprozess während der ganzen Zeit aktiv.

    Wenn die Info was bringt: wir sind auf Xubuntu 18:04LTS

    Irgendwelche Ideen?

  • Ich würde eher in einem Ubuntu-Forum nachfragen, Stichpunkte wären z.B. Desktop, Powermanager, Netzwerkmanager, systemd.

    Hier sind Windows User unterwegs, die wenigsten hier sind mit dem Linux Betriebssystem vertraut.

  • Hier sind Windows User unterwegs

    Korrekt wäre: Hier sind Windows-, macOS- sowie Linux-Nutzer unterwegs.

    Bei Firefox 87.09b (letzte Version, wo wir noch keine Probleme haben) ist dieses Verhalten nicht zu beobachten, da ist der Hauptprozess während der ganzen Zeit aktiv.

    Wenn das Problem erst seit einer bestimmten Firefox-Version auftritt, könntest du bitte mozregression ausführen?

    mozregression

  • Bei Firefox 87.09b (letzte Version, wo wir noch keine Probleme haben) ist dieses Verhalten nicht zu beobachten, da ist der Hauptprozess während der ganzen Zeit aktiv.

    Wenn das Problem erst seit einer bestimmten Firefox-Version auftritt, könntest du bitte mozregression ausführen?

    https://mozilla.github.io/mozregression/

    Danke für den Tipp mit Mozregression! Ich habe über die letzten Tage diverse Versionen durchgetestet bis hin zu 78.0 (das war ja die letzte ESR-Version).

    Leider kommt der Fehler in jeder Version, auch mit den deaktivierten Nightly Experiments, was sehr interessant ist.

    Daraufhin habe ich mir 87.0a1 und die 87.0b9 genauer angeschaut, denn: in 87.0a1taucht der Fehler auf, in 87.0b9 nicht. Ich habe versucht die beiden Versionen weitesgehend von den Einstellungen her anzugleichen, doch bisher leider ohne Erfolg - der Fehler kommt in 87.0a1 nachhaltig.

    Falls du Zeit und Interesse haben solltest, dir das Thema genauer anzuschauen, ließe sich das auf alle Fälle arrangieren – selbstverständlich mit einer entsprechenden Aufwandsentschädigung. PM mich, falls das für dich interessant klingt.

  • Ich konnte tatsächlich eine Lösung finden – schreibe sie hier für den Fall, dass jemand ein ähnliches Problem haben sollte.

    Hinweis auf die Lösung ist mir im Strace-Log aufgefallen – die Meldungen sind in allen von mir getesteten Nightlies aufgetreten, in Release aber erst ab 88.0 – 87.0 bzw. 87.09b hatten diese Aufrufe nicht.

    Diese DRM-Aufrufe starteten immer kürzlich, bevor sich der Hauptprozess aufgehängt hat und daraufhin erst wieder nach dem Entsperren vom Bildschirm.

    Das hat mich in meiner weiteren Untersuchung zu folgenden Ergebnissen geführt:

    • Firefox schaltet ab der Version 88 die Hardware-Beschleunigung per default an – in den Versionen davor ist es ein opt-in.
    • In den Nightlies ist die HW-Beschleunigung schon länger freigegeben.
    • Bei uns liegt ein Problem mit den Intel-Graka-Treibern vor – der i915-Treiber ist zwar installiert, von xorg wird aber der standardmäßige modesetting aufgerufen.
    • Firefox versucht aufgrund der HW-Beschleunigung den Treiber anzusprechen, dieser ist aber nicht aktiv -> Prozess hängt sich auf.

    Vorläufige Lösung:

    Folgende optionen in about:config anpassen:

    • gfx.webrender.force-disabled true
    • layers.omtp.enabled true
    • und ggf. noch layers.acceleration.force-enabled false
    • -> Firefox neustarten.

    In about:support muss Compositing auf Basic stehen und im Entscheidungsprotokoll jegliche Option muss blocked oder disabled sein, außer OMTP.

    Dadurch hören die Prozessabstürze auf.

    Längerfristige Lösung ist für uns natürlich das Treiber-Problem zu beheben ;)

    @Sören Hentzschel vielen Dank für die Unterstützung und insb. auf den Hinweis zu Mozregression – Gegenüberstellung der Logs und Einstellungen von 87.0a und 87.0b hat den entscheidenden Hinweis geliefert.

  • Danke für die Rückmeldung.

    gfx.webrender.force-disabled

    Kannst du das wieder rückgängig machen und stattdessen mit gfx.webrender.software auf true testen? Hintergrund ist der, dass erstgenannter Schalter mit dem nächsten Major-Update des von dir genutzten Firefox ESR nicht mehr existieren wird, weil es mittlerweile nur noch WebRender gibt. Aber mit dem anderen genannten Schalter aktivierst du die Software-Implementierung von WebRender anstelle der Hardware-beschleunigten WebRender-Implementierung. Wenn das Problem wirklich einen Zusammenhang zum Treiber hat, sollte das auch funktionieren, da der Treiber damit auch außen vor ist. Mit dem Vorteil, dass du eine langfristig von Mozilla unterstützte Konfiguration nutzt - und vielleicht schon testen kannst, bevor es keine Alternative mehr gibt. Solltest du nämlich mit Software-WebRender auch Probleme haben, sollten diese idealerweise behoben sein, bevor Firefox ESR den nächsten großen Versionssprung macht.

    Ansonsten, könntest du noch eine Nightly-Version zum Vergleich testen? Die ist in der Entwicklung schon um einige Monate weiter als Firefox ESR 91. Vielleicht ist dein Problem damit ja schon behoben, das wäre natürlich ideal. Ansonsten bitte unbedingt an Mozilla inklusive deiner gewonnenen Erkenntnisse melden. Selbst wenn Firefox für dich so funktioniert. Ich halte es für wichtig, dass Mozilla davon zumindest gehört hat, damit das Problem ggfs. auch behoben wird. Und selbst wenn es nur heißt, den Treiber auf die Blocklist für Hardware-WebRender zu setzen. Dann profitieren zumindest andere Nutzer mit vergleichbarer Konfiguration davon.

  • Zitat

    Bei uns liegt ein Problem mit den Intel-Graka-Treibern vor – der i915-Treiber ist zwar installiert, von xorg wird aber der standardmäßige modesetting aufgerufen.

    Ich nutze den Treiber auf meinem Debian Sid ebenfalls.

    Du solltest in /etc/X11/xorg.conf.d eine xorg.conf anlegen mit diesem Inhalt:

    Zitat

    Section "Device"

    Identifier "Intel"

    Driver "intel"

    EndSection

    Dann wird auch der Intel für i915 statt des modesettings verwendet.

  • Hintergrund ist der, dass erstgenannter Schalter mit dem nächsten Major-Update des von dir genutzten Firefox ESR nicht mehr existieren wird, weil es mittlerweile nur noch WebRender gibt.

    Vielen Dank für die Vorwarnung! Ich werde den Test entsprechend durchführen.

    Welches Update ist damit gemeint? Das 102esr, welches für Juni 22 angesetzt ist?

    Danke für den Hinweis. Werde ich auf meiner Maschine bei Gelegenheit ausprobieren, das ist aber leider keine Änderung, die wir mal fix auf 1,5k Rechnern ausrollen können ;P