steffen

@tom_s Ja, das habe ich mir für Munin selbst erstellt. Notwendig dafür ist die von Michael erstellte "stats". Sie ist via Browser aufrufbar (bei uns) unter:

https://friendica-deutschland.de/stats?key=strenggeheim

"strenggeheim" ist eine Zeichenfolge, die du speziell für dich erstellen solltest (unter: config/local.config.php).

'system' => [
...
'stats_key' => 'strenggeheim'
....
],

Mit diesen Daten konnte ich dann die Munin-Charts erstellen.
Mit einem Cron-Job rufe ich die stats regelmäßig neu ab, damit sich der Chart entwickeln kann.

Alles in allen etwas aufwendig, aber nützlich für einen groben Überblick.

@tux Der Fehler entsteht im Friendica-Worker UpdateBlockedServers. Dieser Worker läuft als tägliche Wartungsaufgabe und geht die bekannten Server aus der gserver-Tabelle durch, um deren Blockierungsstatus neu zu bewerten.

\u0004 ist kein normales Zeichen, sondern das ASCII-Steuerzeichen EOT / End of Transmission, Bytewert 0x04.

Der String sieht also intern ungefähr so aus: merveill<0x04>s.town und nicht etwa wie ein regulärer Hostname.

Guzzle macht deshalb genau das Richtige und verweigert die URI.

@tux Sieht für mich eher nach einem separaten Problem aus. In der gespeicherten Server-URL steckt mit \u0004 ein ungültiges Steuerzeichen, deshalb bricht Guzzle beim Parsen ab.

Ich würde den betreffenden gserver-Eintrag prüfen, am besten auch mit HEX(url). Wichtig wäre noch zu sehen, ob UpdateBlockedServers bei so einem Eintrag komplett abbricht oder nur diesen Datensatz überspringt. Falls er komplett abbricht, könnte das zumindest die Wartungsarbeiten teilweise behindern.

@tux In der verzögerten Warteschlange sind unter anderen (bei uns) auch solche Einträge:

wall-new: 20727751: nrw.social/inbox: 4: {101140: 101422: 103654: 103656: 103657: 192159}: 12757612

Wenn du Stichproben auf die Erreichbarkeit machst, kannst du unter Umständen auch feststellen, dass einige Instanzen derzeit nicht wie gefordert erreichbar sind.

@tux Nein, dann ist es dieser User-Agent bei dir nicht. Eventuell etwas ähnliches? Ich habe unsere Querelen lediglich als beispielhafte Systematik erläutert.

Derzeit vernehmen wir über alle unsere Webserver verstärke "Schädlinge" in Aktionen. Dabei können wir keine gleichen Vorgehensweisen bestätigen. Es ist immer wieder etwas anderes und wir sind gefordert die "Störquelle" immer weiter einzugrenzen, bis wir sie lokalisieren können.

Das ist zeitraubend und ärgerlich. Aber wir müssen reagieren. Wenn so ein Fehler, wie von dir beschrieben, von einem Moment auf den anderen einfach auftaucht, ohne vorherige Veränderungen (z.B.: durch Updates) liegt es nahe mit einer "Störquelle" / "Schädling" zu tun zu haben.

@tux Wir hatten ein sehr ähnlich gelagertes Problem und haben dazu herausgefunden, dass der User-Agent gotosocial/0.22.1+git-fdff42b (+https://social.thingsandcode.com) und ein weiterer unsere Friendica-Instanz bzw. den gesamten Server sukzessive mehr und mehr geschwächt hat. Unter anderen füllte sich dadurch auch die verzögerte Warteschlange.

Zuerst haben wir via ufw die IP's gesperrt und danach in der .htaccess im Friendica-Verzeichnis unter RewriteEngine on folgenden Eintrag eingefügt:

# Problematischer GoToSocial-Build
RewriteCond %{HTTP_USER_AGENT} ^gotosocial/0\.22\.1\+git-fdff42b [NC]
RewriteRule ^(?:friendica|robots\.txt)$ - [F,L]

Danach normalisierte sich alles wieder. Die "Normalisierung" dauerte allerdings einige Stunden.