#ICE843 rollt mit 5 Minuten Verspätung in Dortmund ein uns setzt seine Fahrt weiter in Richtung Hamm fort, wo der Zug mit einem 2. Zugteil gekoppelt wird. 1. Kopplungsversuch fehlgeschlagen, 2. Kopplungsversuch fehlgeschlagen. Jetzt wird der erste Zugteil aufgegeben, alle Passagiere müssen in den zweiten Zugteil.
Der erste Zugteil fällt aus und der zweite muss zurück setzen um den liegen gebliebenen Zugteil auf einem anderen Gleis überholen zu können.
Schon 20 Kilometer gerollt und über eine Stunde Verspätung.
Naja, egal - werde ich halt die Aussicht genießen.
Der Stolz der Familie (und einzige Reinigungsfachkraft) , unser Roborock S7 MaxV ist defekt. Der Roboter findet die Station nicht mehr und nach dem Wachsen des Mopps riecht die ganze Wohnung nach Käsefüßen 😅
Ich vermute, das sich ein Schlauch im inneren der Station gelöst hat, also Schmutzwasser sich in der Station verteilt hat - das würde auch das austreten des Käsefußwassers erklären:
Das Ding ist 14 Monate alt und hat 1,399€ gekostet - mindestens ärgerlich.
Ich bin mal gespannt, was der Verkäufer dazu sagt. Nach 12 Monaten gilt ja schließlich die Beweislastumkehr, aber da mache ich mir noch wenig Sorgen. Bei einem vollständig autonomen System einen Benutzerfehler anzubringen halte ich zumindest noch für relativ schwierig 😀
Besser Spät als nie - der monatliche Report für August 2023 und fast schon September 2023:
Die Sprünge im Ram sind Neustarts des Servers. Diese werden in der Regel nur Nachts und prophylaktisch vorgenommen. Bei Sicherheitskritischen Updates wie Firmware oder ähnlichem auch mal am Tag - Ein Neustart des Servers und aller Services dauert in der Regel 1-2 Minuten.
Wie Ihr am Ram sehen könnt, hatten wir diesen Monat extrem viele Neustarts. Dies lag unter anderem an den schon im letzten Monat berichteten Endlosschleifen. Man kann in der Grafik gut erkennen, das wir diese ab dem 24.08.2023 gut in den Griff bekommen haben (CPU-Graph). Der Bug im Sourcecode ist nicht behoben, aber wir haben eine Möglichkeit gefunden, dem Bug aus dem Weg zu gehen. Da es sich nur um einen Post im Fediverse handelt, haben wir den Post lokal auf unserer Instanz gelöscht und den Absender blockiert - bis der Fehler behoben wird. Die weiteren Neustarts ergeben sich aus einer ungewöhnlich hohen Anzahl an Sicherheits- und Kernelupdates.
Wir haben ein paar neue Features, wie beispielsweise die "Channels", welche vielfältige gefilterte Versionen der vorhanden Posts im Fediverse anbieten - inspiriert von Bluesky. Vielen Dank an dieser Stelle noch mal an die Entwickler von #Friendica , welche keine Mühen scheuen #Friendica stets zu verbessern.
Ansonsten gab es keine erwähnenswerten Vorkommnisse, außer das die Moderation und Schlichtungsverfahren immer weiter zunehmen. Besonders negativ aufgefallen ist diesen Monat rheinneckar.social, welche weder auf Emails reagierten, noch auf Moderationsansuchen. Es handelte sich bei diesem Vorfall um einen offensichtlich rechtsextremen Nutzer, der andere Nutzer beleidigte. Wir haben unsererseits den Kontakt blockiert, den Nutzer auf unserer Instanz informiert und auch eine Mail an die Admins von rheinneck.social gesendet, mit dem betroffenen Nutzer auf BCC - auch da bisher keine Reaktion.
Für die Statistik-Fans: Derzeit haben wir 499 registrierte Nutzer (+20 im letzten Monat), von denen 239 (+22 im letzten Monat) in den letzten 6 Monaten aktiv waren und ca. 124 (+2 im letzen Monat) regelmäßig aktiv sind.
Und wie immer der Zusatz:
Wir speichern weder IP-Adressen, Referer oder User-Agent beim Zugriff auf unseren Dienst. Es kann allerdings sein, dass das Loggen dieser Metadaten kurzzeitig aktiviert wird - beispielsweise bei einer DOS oder DDOS-Attacke - aber auch nur, um technische Gegenmaßnahmen einzuleiten. Das Loggen wird nach solch einem Vorfall direkt wieder deaktiviert und die entsprechenden Logs gelöscht.
Die Instanz läuft wie geschnitten Brot. Keine Endlosschleifen, keine kaputten Anzeigenamen - alles läuft so, wie es soll. Nach 3 Wochen Horror weiß man das durchaus zu schätzen.
@OldKid Hier Hängt sich ja der Worker nicht auf, es sind einfach unendlich viele Datenbankanfragen auf diese Kontakte. Was die Datenbank mit einer CPU -Last von 500% laufen lässt (relativ)
die php-fpm8.0 laufen bis zum max_memory Limit von 1 GB, stürzen dann ab und fangen neu an, die Datenbank zu penetrieren.
Hallo zusammen, es ist wieder soweit - einmal im Monat poste ich den Serverstatus aus Transparenzgründen.
Die Sprünge im Ram sind Neustarts des Servers. Diese werden in der Regel nur Nachts und prophylaktisch vorgenommen. Bei Sicherheitskritischen Updates wie Firmware oder ähnlichem auch mal am Tag - Ein Neustart des Servers und aller Services dauert in der Regel 1-2 Minuten.
Wie Ihr am Ram sehen könnt, lief der Server fast den ganzen Monat stabil ohne Neustarts, außer am 09.07.2023.
Ab dem 31.07.2023 seht Ihr , das der Server ca. 2 mal am Tag neu gestartet wurde.
Dies hat einen Grund: Aktuell kämpfen wir vermutlich mit einem Bug in Friendica.
Es scheint einen Thread im Fediverse zu geben, der dafür sorgt, das sich die PHP-Prozesse in einer Endlosschleife aufhängen, bis der maximale Speicher von 3 Gigabyte pro Prozeess erreicht ist - danach wird dieser abgebrochen.
Das hört sich jetzt nicht dramatisch an, aber da bei uns bis zu 150 Prozesse gleichzeitig laufen dürfen, ist der Ram dann schnell erschöpft.
Also Sofortmaßnahme habe ich das Speicherlimit pro Prozess auf 1 Gigabyte limitiert.
Bisher scheint es keine Abhilfe zu geben und so wie es aussieht ist vorerst nur diese Instanz betroffen. Das kann sich schnell ändern, wenn der Thread auch andere Friendica-Instanzen erreicht. Die ist nun das 3. mal, das wir hier "Vorreiter" waren - echte Pionierarbeit 😉
In der Regel dauert es 1-2 Wochen, bis ein Dev über so einen Vorfall auf seiner eigenen Instanz aufmerksam wird und dann ist solch ein Vorfall auch schnell behoben -so zumindest die Erfahrungswerte.
Bis dahin muss ich halt 2-3 am Tag den Server neu starten, damit dieser Stabil weiterläuft.
Ich habe #friendica.opensocial.space heute auch auf die Entwicklungsversion 2023.09-dev angehoben, in der Hoffnung, das sich irgendwo in dem neuen Code ein fix verbirgt, dem war aber leider nicht so.
Für die Nutzer dieser Instanz sollte sich dennoch nichts ändern, außer das das System insgesamt über den Tag verteilt mal 3-6 Minuten nicht erreichbar ist 😀
Das System kann derzeit aufgrund der Endlosschleifen etwas träger sein als sonst (aber auch nicht akut langsamer) - ich bitte dies zu entschuldigen, aber leider liegt dies außerhalb meines Wirkungsbereiches.
Ansonsten gab es keine erwähnenswerten Vorkommnisse, außer das die Moderation und Schlichtungsverfahren leicht zugenommen haben.
Für die Statistik-Fans: Derzeit haben wir 479 registrierte Nutzer (+60 im letzen Monat), von denen 217 (+4 im letzen Monat) in den letzten 6 Monaten aktiv waren und ca. 122 (+11 im letzen Monat) regelmäßig aktiv sind.
Und wie immer der Zusatz:
Wir speichern weder IP-Adressen, Referer oder User-Agent beim Zugriff auf unseren Dienst. Es kann allerdings sein, dass das Loggen dieser Metadaten kurzzeitig aktiviert wird - beispielsweise bei einer DOS oder DDOS-Attacke - aber auch nur, um technische Gegenmaßnahmen einzuleiten. Das Loggen wird nach solch einem Vorfall direkt wieder deaktiviert und die entsprechenden Logs gelöscht.
@Detlef Krusekopf Kurios - ich nutze auch Opera und da funktioniert es. Du hast auf jeden Fall nichts verpasst:
Warum die bei dir nicht korrekt angezeigt werden - puh - da habe ich keine wirkliche Idee. Ich verstehe zwar die technischen Hintergründe warum es so sein könnte - aber da sind je nach Setup X variablen 🙁
