github stats have rallied up as well

On master, 1,786 files have changed and there have been 192,556 additions and 103,309 deletions.

But I still think they should not only track the master branch in their graphs as it is misleading for judging the activity of a project.

Ja genau so. Funktioniert alles. dynDNS mache och über freedns.afraid.org, die Domain hab ich mir irgendwo gekauft und dann den dynDNS Nameserver eingetragen. Auf dem RasPi läuft ein IP Detect was ein Shell Script aufruft wenn IP von außen gesehen unterschiedlich zu der ist, die es das letzte mal hatte. Und das Scipt macht im wesentlichen einen curl Aufruf bei freedns um die geänderte IP Adresse an den DNS weiter zu geben. Kostet bei freedns damit sonst niemand deine TLD verwenden kann (das ist ansonsten der Deal, wenn es umsonst sein soll).

Es gibt auch die Funktion in Routern, dass die dynDNS automatisch machen können. Aber so ist die Lösung unabhängig von einem u.U. wechselndem Router.

TLS Zertifikat kommt über LetsEncrypt ganz normal. Wobei dadurch dass ich da eine eigene domain drauf geschaltet habe auch eine eMail Verifikation möglich wäre.

Mir hat das Update jetzt viermal hintereinander zuverlässig irgendeinen nicht-friendica-Prozess durch Out-of-Memory abgeschossen. Dreimal war's der Datenbankserver, einmal ein diaspora-Prozess (ein Schelm, wer arges dabei denkt).

Das ließ sich nichtmal durch starkes Zusammenstreichen der PHP-FPM-Prozesse vermeiden.
Dem Anschein nach hat der Cronjob einfach so lange geforkt, bis alle Ressourcen verbraucht waren, um die Datenbank-Updates zu machen.

Das hat jetzt keinen größeren Schaden angerichtet (zwei Diaspora-Kommentare sind mir dabei flöten gegangen, geschenkt), ein entsprechender Hinweis, daß der Update-Prozeß nicht nur lange dauern sondern auch viel RAM verbraten kann, wäre schön gewesen. Oder eine Möglichkeit, das von Hand selbst zu machen, um zu wissen, wann das passiert, wann es zu ende ist und vor allem, wieviel Ressourcen man dafür braucht.

Das Phänomen hat bislang niemand berichtet. Am Besten deaktivierst Du den Crontab-Aufruf temporär und rufst dann php include/dbstructure.php update direkt in der Kommandozeile auf.

Und - wie @Utzer schon sagte - aktiviere den Worker. Der ist zuverlässiger bei der Hintergrundverarbeitung.

Bei den Workern? Kommt drauf an wie die Ressourcen sind. Ich hab auf dem RasPi 4 als Obergrenfe angegeben und eine maximale Load von 8, also das doppelte von den 4 Kernen des RasPis.

Michael Vogel hat für pirati.ca IIRC 10 aktiv.

Ohne Worker.
Stand halt nicht im Upgrade-Guide.

Das Ding läuft als Quasi-Single-User-Instanz auf einer vergleichsweise schmalen VM (4GB RAM) und da hat tatsächlich der Cronjob beim Upgrade mit einer wirklich beeindruckenden Menge an PHP-Tasks alles gefressen.

Nachdem jetzt die Worker aktiv sind, ist es auch nicht mehr vorgekommen.

Ein Hinweis Marke "Schalte den Cronjob ab, konfiguriere Worker und/oder mache dbstructure.php upgrade, starte den Cronjob, fertig" wäre ausreichend gewesen.

Ist ja nix passiert/verloren gegangen, also ist es damit für mich erledigt.

Ich werde nach dem Frühstück was dazu schreiben in die Release Notes. Von meiner Statistik waren etwa 30 Leute auf dem RC Branch, einige von denen kamen vom devel, andere vom master. Wie Michael schon sagte hat niemand von so einem Problem berichtet.

Also dange für's berichten Felix

@Tobias Ich war/bin auf dem master Branch, die VM hat 4GB RAM und einen CPU-Core.
Es fing mit seeeeeehr vielen PHP-Prozessen an und fraß dann sämtliches Memory, bis der Kernel anfing, Tasks rauszuwerfen, vorzugsweise den mysqld. Danach starben dann die PHP-Tasks und das Memory wurde freigegeben.

Ich muß auch selbst mal nachforschen, warum ein unprivileged User überhaupt Prozesse anderer User absterben lassen konnte, das sollte IMHO nicht möglich sein.
friendica selbst hätte abgeschossen werden sollen, aber nicht mysqld oder diaspora (beides andere User).

Ich gebe Euch beiden erst mal Recht. Der ganze Artikel zeigt aber auch, dass sich Leute die sich nicht intensiv mit Friendica beschäftigen, sehr schnell abgeschreckt werden.

Soll heißen ein "Otto Normaluser" findet sich in dem Git Jungel in keinster Weise zurrecht. Als Beispiel kann ich mich selbst nennen. Ich wollte mir dieses neue Template installieren und habe mir die Sourcen dafür gezogen und manuell installiert. Lief nicht.

Dann wurde mir gesagt, dass es schon im Repository enthalten ist. Nur wusste ich nicht, dass es nur im Dev enthalten aber nicht im Stable.

Das sind so Kleinigkeiten, die es für die breite Masse schwer macht, sich bei Friendica einzarbeiten. Für Tekkies ok, für Normalos schwer.

Wir bräuchten jemanden (tm) der eine völlig neue Webseite ohne viel Ballast erstellt, auf der wir ohne viel Blabla Dinge erklären.

Wir haben die Domain, wir könnten sicherlich auch einen unserer Server verwenden (z.B. den von snarl), wir bräuchten nur ein einfaches CMS und jemand, der Inhalte einstellt.

Oder aber wir gehen mit friendi.ca zu einem der Bloganbieter wie Tumblr, Wordpress oder Blogger. Dann haben wir den Vorteil, dass wir uns nur um Inhalte kümmern müssen. Und es läuft auch, wenn es Serverprobleme gibt.