Lightning + CalDAV + NextCloud: unerklärliche Verzögerung und Systemlast auf dem Server

    Hallo!

    Akteure des nachfolgenden Dramas sind:

    - ein Server mit Debian Buster (LEMP)

    - NextCloud 17

    - ein Linux-Rechner

    - TB60+Lightning

    - TB68+Lightning

    Der Server wurde nach der Anleitung von NextCloud.com eingerichtet.

    1. Akt: TB68

    Bei der Verwendung von TB68 oder höher und Lighting und dem Zugriff auf einen Kalender aus NextCloud entsteht zum einen eine Pause von mehr als über 10 Sekunden, bis ein neu eingegebener oder bearbeiteter Kalendereintrag nach dem Klick auf "Speichern" auch angezeigt wird, zum anderen steigt die Systemlast auf dem Server beim Abruf mehrere Kalender oder dem Import mehrere Ereignisse ins Uferlose.

    Der Reihe nach:

    1. Szene:

    Ich gebe einen neuen Termin ein und klicke auf "Speichern". Der Termin ist zunächst nicht zu sehen, und auf dem NextCloud-Server erscheint erst nach (genau!) 6 Sekunden dieser Eintrag im Log vom mysql:

    ... "PUT /http://remote.php/dav/calendars/...

    Dann dauert es genau weitere 5 Sekunden, bis zu diesem Eintrag:

    ... "REPORT /http://remote.php/dav/calendars/...

    Und erst jetzt erscheint der neue Termin in Lightning!

    2. Szene:

    Ich importiere einen Kalender mit mehr als 150 Einträgen. TB steht, reagiert nicht mehr, und auf dem Server steigt die Systemlast bis über 40 an (cat /proc/loadavg), und der Import ist auch nach über 30 Minuten(!) noch nicht abgeschlossen.


    2. Akt: TB60

    Wird TB60.x+Lightning verwendet, läuft alles wie am Schnürchen: ein Termin wird eingegeben, und nach dem Klick auf "Speichern" quittiert mysql auf dem Server diesen Termin sofort und er wird noch innerhalb derselben Sekunde in Lightning angezeigt.

    Wird derselbe Kalender wie zuvor mit 150 Einträgen in TB60.x importiert, reagiert auch hier der Server sofort, die Systemlast steigt nur minimal an (bis ca 3), und der Import ist in wenigen Sekunden(!) erledigt.

    Epilog:

    Dieses unterschiedliche Verhalten kann ich beliebig oft wiederholen, egal ob mit neu angelegten oder alten Profilen: in TB60 flutscht es, in TB68 kriecht es. Es spielt auch keine Rolle, ob die Unterstützung für den Offline-Modus in einem Kalender aktiviert ist oder nicht, der Unterschied bleibt stets derselbe. Der gleiche Unterschied zeigt sich, wenn ich auf meinem Rechner ein Live-System starte, das sich von meinem eigenen System unterscheidet und dort TB60 gegen TB68 antreten lasse.

    Gibt es Leidensgenossen? Oder gar eine Lösung für dieses Problem?

    Quote from Papierflieger

    Gibt es Leidensgenossen?

    Oh ja! Eine Lösung habe ich leider nicht, aber einen ähnlichen Leidensweg und einen eher schlechten als rechten workaround.

    Seit Einführung der Version 68 scheint irgendetwas nicht mehr mit Cal-/CardDav zu stimmen. Da beißt die Maus keinen Faden ab.

    Es gibt so einige Problemberichte, ganz unterschiedlicher Natur. Bei mir hat es im Zusammenspiel mit NextCloud auch ordentlich geklemmt.

    Meine "Szenen":

    Ich hatte zunächst die NCPi installiert, bin dann mit etwas Hilfe auf die snap-version gegangen. Die gesamte Cloud lief prima und ausreichend performant. Fotos, Videos - alles gut. Egal ob von PC oder Phone aus.

    Dann kam Thunderbird 68. Die Performance von Kalender und Cardbook war grottenschlecht. Nur im TB und nur mit der 68. Andere Programme und Clients auf den Smartphones liefen weiter wie geschmiert. Das war beliebig reproduzierbar mit nur einem Kalender und jeweils einem neuen Profil. 60 hui, 68 pfui.

    Ich habe im Internet gesucht und Berichte von anderen Leidtragenden gefunden, in diesem Forum hier und auch in Artikeln zu Cardbook, Nextcloud, Radicale usw. . Da ging es bis zum Hängen des Servers. Dabei geht es gewiss um unterschiedliche Probleme. Die Gemeinsamkeit ist das Update auf Thunderbird 68.

    Nähere Hinweise auf die Ursachen habe ich nicht finden können, außer dem typischen wenn ich gar nichts weiß dann sage ich AV. Von seriöser Seite habe nur Spekulationen gefunden. Ansonsten Schweigen.

    Ich habe dann selbst viel getestet und getraced. Die Ursache habe nicht finden können. Gegenwärtig scheint es aber, als hätte ich Situation für mich durch einen Zufallsfund verbessern können.

    Um das Problem besser untersuchen zu können habe ich alles etwas entzerrt. Ich hatte noch einen alten Raspberry B+. Für die NC ist der zu schwach, aber für *DAV über einen Radicale genügt er. Damit lief auch die 68 zunächst gut.

    Wie ich dann feststellen durfte, galt das nur für Phones und Linux PCs. Unter Windows 10 gab es mit TB 68 erneut Probleme. Das ging unvorhersehbar tatsächlich bis zum Hängen des Radicale Servers. So, wie ich es auch von anderen gelesen hatte.

    Um das weiter zu untersuchen, habe ich das Abrufen vom DAV-Server weiter entzerrt, indem ich Cardbook erst nach 120 Sekunden synchronisieren ließ. Dadurch ist mir aufgefallen, dass es im Falle einer Störung bereits beim Kalender hing. Ich konnte die Hänger dann auch ganz ohne Cardbook erzeugen.

    Dann habe ich zusätzlich die Offline-Unterstützung im Kalender abgeschaltet. Siehe da, keine Hänger mehr. Gegenprobe, Offline-Unterstützung wieder an und schon klemmte es wieder. Das betrifft wie erwähnt nur TB 68 unter Windows.

    Abschalten der Offline-Unterstützung für Kalender in der NC brachte nicht den gewünschten Erfolg. Die NC habe ich mit dem TB 68 nicht performant ans Fliegen bekommen.

    Inzwischen habe ich ziemlich die Nase voll und keine Lust mehr auf den Mist. Das kostet unglaublich viel Zeit. Die weiß ich wirklich besser zu verbringen.

    Die Kalender und Adressbücher habe ich jetzt testweise bei einem Provider. Die haben zu Weihnachten 6 Monate verschenkt. Vielleicht findet bis dahin jemand heraus, was mit dem Kalender in der 68 nicht stimmt. Wenn nicht, bezahle ich halt für einen funktionierenden Service oder benutze meine Hybrid-Krücke aus NC und Radicale.

    Irgendwie tut es gut zu wissen, mit einem Problem nicht alleine dazustehen. :)

    Bei mir macht das Abschalten der Offline-Unterstützung keinen Unterschied. Wenn es jedoch daran läge, müsste der Fehler eher in der TB Umsetzung von SQLITE zu suchen sein, denn damit speichert TB die Kalender lokal ab. Das kann ich aber durch entsprechende Tests ausschließen.

    Meine Vermutung geht eher in eine andere Richtung: starte ich TB68 über die Konsole, erscheinen dort Fehlermeldungen wie diese, wenn ich Kalendereinträge synchronisieren:

    Code
    console.warn: Lightning: Parsing failed for parts of the item (while this is considered to be a minor issue, we continue processing the item):
...
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an 
illegal type for property: VALUE=DURATION
DESCRIPTION:Mozilla Standardbeschreibung

    Es könnte sein, daß TB68 die EVENTS in dem Kalender irgendwie misshandelt und verhackstückelt, NC sie zwar wieder reparieren kann, was aber Rechenzeit kostet. Dass die Dauer eines Ereignisses nicht zulässig ist, sollte vielleicht zu denken geben:

    illegal type for property: VALUE=DURATION

    Wenn ich aber an der GUI von NC anmelde und einen solchen Termin exportiere und mir im Texteditor ansehe, ist kein Fehler enthalten. Also muss zwischen der Übermittlung von TB68 und dem Speichern in NC etwas damit passieren.

    Quote from NumLock

    Wenn nicht, bezahle ich halt für einen funktionierenden Service oder benutze meine Hybrid-Krücke aus NC und Radicale.

    Oder du machst es wie ich und gehst wieder zu TB60 zurück. damit läuft es einwandfrei.

    Übrigends: auch mit SeaMonkey funktioniert die Synchronisation mit NC einwandfrei.

    Der Schuldige ist einwandfrei TB68!

    Quote from Papierflieger

    starte ich TB68 über die Konsole, erscheinen dort Fehlermeldungen wie diese, wenn ich Kalendereinträge synchronisieren:

    Ich hatte auch Meldungen in der Konsole. Die konnte ich aber nicht interpretieren. Eine richtig lesbare Fehlermeldungen, wie bei dir, habe ich nicht gesehen.

    Hast du mal nachgelesen, ob gemäß RFC

    Code
    VALUE=DURATION:-PT30M

    erlaubt ist? Das - erscheint mir schon komisch. Steht das überhaupt so in dem Termin?

    Quote from Papierflieger

    Der Schuldige ist einwandfrei TB68!

    Schuldig ist vielleicht etwas zu stark formuliert. Es spricht jedoch tatsächlich alles dafür, dass hier die Ursache liegt.

    Quote from Papierflieger

    Oder du machst es wie ich und gehst wieder zu TB60 zurück. damit läuft es einwandfrei.

    Mit der 60 läuft es einwandfrei. Das ist richtig. Einfach nicht upzudaten ist aber auch keine gute Idee. Ich hoffe ja immer noch, dass jemand den oder die Fehler findet und beseitigt.

    Ja klar, das stimmt schon. Wenn man es nicht meldet, sollte man sich nicht beschweren oder eine Erwartung aufbauen. Ich werde mich aber nicht weiter engagieren. Wenn das jemand, also ein Entwickler, untersuchen soll, der es nicht selbst reproduzieren kann, benötigt er ausreichend Daten. Das alles hat mich aber locker bereits 15 Stunden Zeit gekostet, die ich wirklich besser hätte verbringen können. Da werde ich nicht nochmal von vorn beginnen und all die erforderlichen Daten generieren. Ich bin im Moment halbwegs zufrieden mit der Lösung, die ich am Laufen habe.

    Es kommt noch was hinzu. Das mit der Offline-Unterstützung ist wohl nur Teil eines der verschiedenen Probleme, denn bei Papierflieger trifft es ja nicht zu. Jedoch liest man seit Jahren, auch hier, dass es damit immer wieder mal hakt. Genauer untersucht hat das anscheinend in all der Zeit niemand oder nicht vollständig oder was auch immer.

    Das ist bitte kein Vorwurf an irgendjemanden. Ich weiß ja um die im Vergleich zu Firefox sehr begrenzten Ressourcen und Mittel.

    Quote from NumLock

    erlaubt ist? Das - erscheint mir schon komisch. Steht das überhaupt so in dem Termin?

    Nein, so steht das natürlich nicht im Termin, so gebe ich ihn nicht ein. Ich gebe meine Termine über die Funktion "neue Termine" ein und fülle dort aus, was ausgefüllt werden muss und kann: Bezeichnung, Datum, Uhrzeit, evtl. Wiederholung und Alarm. Diese seltsame Dauer des Termins kommt erst danach irgendwie hinzu, wenn TB68/Lightning den Termin an den CalDAV-Server übermitteln will.

    Aber: lasse ich anschließend den Termin über die GUI von NextCloud exportieren und schaue ihn im Texteditor an, sieht alles so aus, wie es sein sollte. Auch ein sql-dump des Termins auf der Konsole zeigt keine Auffälligkeiten.

    Wie ich sagte: es sieht so aus, als wenn Lightning den Termin verunstaltet und NextCloud es wieder korrigieren muss.

    Quote from Thunder

    Zumindest sind Eure differenzierten Beobachtungen und Tests wichtig, um in BugZilla so gemeldet zu werden, denke ich.

    Habe ich schon getan.


    Quote from NumLock

    Das ist bitte kein Vorwurf an irgendjemanden. Ich weiß ja um die im Vergleich zu Firefox sehr begrenzten Ressourcen und Mittel.

    Der Thunderbird galt ja auch schon mal als "fertig" und sollte ganz aufgegeben werden...

    Hi!

    Ich habe den gerade herausgekommenen aktuellen TB 68.4.1 ausprobiert, mit einem komplett neuen Profil, aber die Verzögerung bleibt.

    Übrigens bin ich bei meiner Suche im Netz nach Hinweisen auf diesen Fehler auch auf viele Berichte über sehr hohe Prozessorauslastung durch TB68, bis hin zum Einfrieren des Programms für viele Sekunden. Auch soll es beim Erstellen neuer Nachrichten manchmal auch vorkommen, dass eingegebene Buchstaben erst viele Sekunden später im Fenster erscheinen. Bei vielen dieser Berichte ist die Rede davon, dass diese zeitgleich mit der Synchronisierung des Kalenders auftrete.

    Meiner Meinung nach wäre TB68 ein Fall für einen Produktrückruf.

    Quote from Papierflieger

    Meiner Meinung nach wäre TB68 ein Fall für einen Produktrückruf.

    Das würde nur leider noch mehr Durcheinander und Ärger für die betroffenen Leute bedeuten. Der ganze (zwangsweise) Umbruch hin zu einer Art Webanwendung des Thunderbird ist leider so sehr viel komplexer als bei einem Webbrowser - zumal, wenn man den Übergang "sanft" gestalten will.

    Guten Tag,

    ich habe auf meinem NAS im HO einen Kalender (Synology Diskstation) am laufen. Dort werden Termine zentral verwaltet (so der Wunsch), die über 2 Smartphons, ein Tablet (jeweils Android, verschiedene Versionen) und zwei PC's (Win10 und Ubuntu) eingetragen und Synchronisiert werden. Nun ist seit längerer Zeit folgendes Phänomen zu erkennen.

    1. Termine werden ordnungsgemäß synchronisiert

    2. Erinnerungen vervielfachen sich, obwohl keine Änderung an dem ursprünglichen Termin vorgenommen wurden.

    3. Im TB kann man weder unter Win10 noch unter Ubuntu die Erinnerung löschen.

    4. Erinnerungen können nur im zentralen Kalender auf dem NAS gelöscht werden.

    5. Bei wiederholende Terminen vervielfältigen sich die Erinnerungen dermassen stark (weit über 1000), dass TB und u.U. das OS zum Stillstand kommt. Die CPU-Last steigt dabei auf nahezu 100%.

    Hier scheint ein grundsätzlicher Bug im TB zu existieren. nach einem export des Kalenders als *.ics file habe ich festgestellt, dass sporadisch Fehlermeldungen im *.ics file existieren, die für mich nicht nachvollziehbar sind.

    X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for LOCATION property. Removing entire property:

    X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION

    Hat jemand eine Idee, wie man diesen Bug beseitigen kann ? Ich kann ja nicht jedes mal den Kalender exportieren, löschen , händisch korrigieren und dann wieder importieren. Dass kann es ja wohl nicht sein !

    Viele Grüße

    Bernd

    Edit: Um die Auswirkungen unerwünschten Doppelpostings zu vermeiden, auf obigen Beitrag nur hier #20 antworten. graba, Gl.-Mod.

    Edited once, last by graba (March 20, 2020 at 2:54 PM).

    Danke Papierflieger,

    Ich habe gehofft, dass es im Forum jemanden gibt, der eine Lösung für das Problem hat. Leider ist dem nicht so. Habe auch von edvoldi (Moderator) eine "Rüge " bekommen, weil ich erwartet habe, dass jemand das Problem liest, versteht und beseitigt, aber "wir sind keine Programmierer..."

    Nun ja, vielen Dank an Dich. Dann werde ich versuchen die "verschlimmbesserte" Version TB68 zu entfernen und wieder auf TB60 zurückzugehen. Erinnert mich aber irgendwie an das OS mit dem bösen "W" :-))

    Bleib gesund !!!

    Quote from Rosinante

    Dann werde ich versuchen die "verschlimmbesserte" Version TB68 zu entfernen und wieder auf TB60 zurückzugehen.

    Du hast oben nicht erwähnt, dass deine Probleme erst mit der Version 68 auftraten. Ist das denn überhaupt so? Deine Beschreibung hört sich für mich so an, als gäbe es bei dir ein Rechteproblem. Die würden sich dann auch mit der Version 60 zeigen.

    Hallo,

    ich bin von allem betroffen, was ihr auch schreibt. Das tut gut zu wissen, dass man nicht alleine ist.

    Frage 1) Wann ist evtl. mit Abhilfe zu rechnen durch die nächsten TB-Versionen? Ich habt vll ein bisschen Erfahrung. Eher so in Tagen, 2 Wochen, 4 Wochen, Monaten? Grobe Einschätzung, ohne dass euch jemand drauf festnagelt.

    Frage 2) Hat schon jemand versucht, mit den folgenen, noch nicht veröffentlichten Versionen für Abhilfe zu sorgen? Beta ist ja gerade Version 75, vielleicht gibt es bei den dazwischen Hoffnung auf Stabilität und Fehlerbehebung? Jemand Erfahrung mit diesen konkreten Versionen?

    Grüße

    Hallo SimBeam!

    Habe mir gerade mal den TB 75b geladen, aber die oben beschriebene Verzögerung ist immer noch drin. :(

    Aaaaber ich habe noch etwas herausgefunden: zur Kontrolle habe ich auf meinem Arbeitsrechner eine lokale Nextcloud als Snap-Paket installiert und den TB 68 darauf einen Kalender nutzen lassen. Und hier gibt es keine Verzögerung. Sofort nach dem Klick "Speichern" ist der Termin sichtbar.

    Daraufhin habe ich nach Unterschieden in den Konfigurationsdateien des ganz oben beschriebenen Servers und den entsprechenden Dateien im Snap-Paket. Die Konfiguration von NC und von MySQL ist identisch, aber das Snap-Paket nutzt Apache statt Nginx.

    Am nächsten verregneten Wochenende werde ich ausprobieren, was passiert, wenn ich das Snap-Paket "Nextcloud" auf demselben Server wie oben beschrieben laufen lasse. Mit einem anderen Port sollte der gleichzeitige Betrieb von Nginx und Apache möglich sein, und da das Snap-Paket auch eine eigene MySQL-DB mitbringt, gibt es da auch keine Beeinflussung. Irgendwie bin ich schon auf das Ergebnis gespannt.

    Hallo,

    bei mir (Thunderbird 68.3.1 64bit, Windows 10, Nextcloud 17.0.5) gibt es dieses Problem nicht. Ich merke im Gegenteil eine Beschleunigung im Vergleich zu einer früheren Anbindung an eine ältere Owncloud.

    Allerdings habe ich Nextcloud nicht auf einem eigenen Server, sondern bei meinem Webspace-Provider laufen.

    Vielleicht hilft das bei der Eingrenzung.

    Viele Grüße

    SSL-Mailer

    SSL-Mailer: interessant... Was macht Windows und dein externer Anbieter denn wohl anders?

    Hast du Shell-Zugriff zu deinem Server? Wenn ja: könntest du dich mal anmelden und das Log von mysql mitlesen, während du einen Termin in TB eingibst und schauen, ob "PUT" und "REPORT" sofort ausgeführt werden?

    Nur, um auszuschließen, daß es irgend ein Caching in Windows gibt, daß die sofortige Abarbeitung des Befehls vorgaukelt.

    Hoppla!

    Ich glaube, ich bin soeben zufällig auf die Lösung des Problems gestoßen:

    ich habe in der Web-GUI der NC für den TB 68 ein eigenes App-Passwort generiert. Bisher habe ich beim Abonnieren der Kalender stets mein Web-PW angegeben, so, wie ich es seit Jahren gewohnt bin. Seit TB68 das eigene App-PW benutzt, sind die Verzögerungen weg: neue Termine sind fast sofort sichtbar, gelöschte Termine verschwinden fast sofort.

    Kann das bitte jemand von den anderen Betroffenen gegenprüfen?