Session-Abstürze seit dem Update auf 91.0ESR

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ß!

Zitat von Sören Hentzschel

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.

Zitat von grisu2099

Zitat von enginegoat

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.

Zitat von Sören Hentzschel

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.

Zitat von Sören Hentzschel

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?

Zitat von Sören Hentzschel

Zitat von enginegoat

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.

9043  10:48:20.501335 ioctl(83, DRM_IOCTL_GEM_CLOSE, 0x7f5c868bc980) = 0 <0.000004>
9043  10:48:20.501353 ioctl(83, DRM_IOCTL_I915_GET_RESET_STATS, 0x7f5c868bca10) = 0 <0.000004>
9043  10:48:20.501372 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc9c4) = 0 <0.000004>
9043  10:48:20.501388 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc9a4) = 0 <0.000004>
9043  10:48:20.501404 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc8c0) = 0 <0.000004>
9043  10:48:20.501418 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc940) = 0 <0.000004>
9043  10:48:20.501434 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc8c0) = 0 <0.000004>
9043  10:48:20.501448 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc940) = 0 <0.000004>
9043  10:48:20.501508 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc040) = 0 <0.000004>
9043  10:48:20.501545 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc040) = 0 <0.000004>
9043  10:48:20.501570 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc040) = 0 <0.000004>
9043  10:48:20.501593 ioctl(83, DRM_IOCTL_I915_GEM_BUSY, 0x7f5c868bc040) = 0 <0.000004>
9043  10:48:20.501628 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc384) = 0 <0.000004>
9043  10:48:20.501644 ioctl(83, DRM_IOCTL_I915_GEM_CREATE, 0x7f5c868bc350) = 0 <0.000014>
9043  10:48:20.501669 ioctl(83, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7f5c868bc344) = 0 <0.000011>
9043  10:48:20.501691 ioctl(83, DRM_IOCTL_I915_GEM_PWRITE, 0x7f5c868bc380) = 0 <0.000008>
9043  10:48:20.501724 ioctl(83, DRM_IOCTL_I915_GEM_CREATE, 0x7f5c868bc190) = 0 <0.000009>
9043  10:48:20.501744 ioctl(83, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7f5c868bc184) = 0 <0.000017>
9043  10:48:20.501772 ioctl(83, DRM_IOCTL_I915_GEM_MMAP, 0x7f5c868bc1a0) = 0 <0.000013>
9043  10:48:20.501798 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc1a4) = 0 <0.000004>
9043  10:48:20.501819 ioctl(83, DRM_IOCTL_I915_GEM_MADVISE, 0x7f5c868bc1a4) = 0 <0.000004>
9043  10:48:20.501849 ioctl(83, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7f5c868bc590) = 0 <0.000032>
9043  10:48:20.501894 ioctl(83, DRM_IOCTL_I915_GEM_THROTTLE or DRM_IOCTL_RADEON_CP_RESUME, 0) = 0 <0.000004>

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.

Zitat von Sören Hentzschel

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?

Zitat von clio

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.

Alles anzeigen

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