>>129308
Il chanal da dieta è e resta tudestg! Ed el è perfetg uschia sco quai ch'el è! Sche insumma, lura mancass qua sin il pli anc /reto/ per in barat rumantsch! Ed ussa ta morda inavo a la fora, or da la quala ti es rut!

https://imagemagick.org/script/security-policy.php
Wenn es damit geht die Datei gar nicht erst zu laden ist vielleicht ein Schutz vor so einem DoS über file properties möglich.
Ich gönne mir jetzt erstmal Miqo'te am Nachmittag.

>Leider legt systemd keinen Coredump an, weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird :/
Dann eben doch Lokal in einer VM testen :(
Da kann man RAM ja recht gut limitieren und den Wert des Servierers replizieren. Sollte halt nicht passieren, dass es so große PNG gibt an denen sich ein file property Ausleser verschluckt.

Vielleicht gibt es einen Speicher-sicheren Fallzurück für Eigenschafts-Ausleser. Guhgel findet u.A.
https://www.imagemagick.org/discourse-server/viewtopic.php?t=31438

>weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird
Äh, wobei, vielleicht auch nicht. Aber auf jeden Fall wird kein Coredump gespeichert aus irgendeinem Grund.

>>129467
Ok, also es ist definitiv ImageMagick, das vom OOM-Killer gekillt wird. Dietchan scheint danach irgendwie zu crashen, aber nur bei dir und nicht bei mir. Leider legt systemd keinen Coredump an, weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird :/

Nach 5x Versuchen/Crème-Küchlein ist der RAM zugekleistert, wenn man die Hochlad-Warnung ignoriert und es einfach probiert. Scheint wohl trotz Crash was im Speicher rumzulungern. Wenn das Speicherloch zu einer Pâtisserie verkommen ist passt nichts meer rein und OOM lässt erstmal die Vannillesoße ablaufen.

>>129458
Probier es gerne nochmal. Konnte es bisher leider noch nicht exakt reproduzieren. Nur der ImageMagick-Prozess stürzt ab, was zwar ärgerlich ist, aber da kann man nichts machen, Softwareproblem.

>>129455
>Was aber auffiel, war, dass während des Hochladens der magick identify-Subprozess sehr viel Speicher verbrauchte und eine sehr hohe CPU-Auslastung generierte.
Das ist in der Tat ungewöhnlich, der Prozess sammelt ja nur Eigenschaften der Datei.
Ich habe aus Neugierde nachgelesen:
<Filename[frame #] image-format widthxheight page-widthxpage-height+x-offset+y-offset colorspace user-time elapsed-time
>Folglich crashte der Prozess dann auch (noch nicht sicher ob "echter" Crash oder OOM-Kill).
Würde man auf einer heimischen VM als Testserver in den logs soetwas sehen bevor der Crash auftritt? Weiss nicht welcher Prozess was schreibt. Gerade systemd loggt ja ziemlich viel nutzlosen Kram.
>Hilft auf jeden Fall!
Gerne geholfen, wäre arschig wenn mir was auffällt und ich es nicht melde.
>Kein Ding.
Okay solange es nicht wieder passiert, wenn dann war es ein anderer Nutzer ;)
Ich probiere daran jetzt nicht mehr rum.

>>129452
>Sorry für den erneuten Test, aber in der Tat, eine 8599x6709 pixel PNG + (diese) PDF == Speicher am lecken.
Ein Speicherleck in dietchan scheint es nicht direkt zu sein. Habe das gerade auch mal getestet und der Hochlad schlug zwar fehl, aber dietchan ist nicht abgestürzt. Am Speicherverbrauch hat sich auch nichts geändert. Was aber auffiel, war, dass während des Hochladens der magick identify-Subprozess sehr viel Speicher verbrauchte und eine sehr hohe CPU-Auslastung generierte. Folglich crashte der Prozess dann auch (noch nicht sicher ob "echter" Crash oder OOM-Kill). Scheint also ein Problem in ImageMagick zu sein. Was mir noch nicht klar ist, ist, warum das anscheinend manchmal dazu führt, dass der Elternprozess vom OOM-Killer (mit-)abgeschossen wird. Das könnte ein separater Bug in dietchan sein oder irgendeine merkwürdige Heuristik des OOM-Killers.

>Ich hoffe der Fehler lässt sich jetzt im Code fixen mit der Info
Hilft auf jeden Fall!

>Tut mir leid für die zweite Downtime!
Kein Ding.

Sorry für den erneuten Test, aber in der Tat, eine 8599x6709 pixel PNG + (diese) PDF == Speicher am lecken. Ich hoffe der Fehler lässt sich jetzt im Code fixen mit der Info. Tut mir leid für die zweite Downtime!

>>129351
>stößt Felix mal den Faden bevor er ihn durchstöbert
Und was hast du so gelernt?

>>129414
https://www.der-postillon.com/2017/06/russische-hacker.html
Dann war das war bestimmt der Kreml!

>>129411
War das erste mal, dass dieses Problem aufgetreten ist. Ein Speicherleck wurde bisher nicht beobachtet.

>>129407
Hmm, vielleicht mal mit RRD-tool loggen wie Systemmetriken über die Zeit verlaufen. Vielleicht war das Speicherleck schon Stunden vorher da?

>>129403
>>129402
>Hat der upload was gekrasht oder war das nicht relatiert?
Keine Ahnung, der Prozess wurde vom OOM-Killer gekillt. War auch nicht mehr viel freier RAM verfügbar, nicht sicher wieso. Die Datei selbst scheint es nicht ausgelöst zu haben >>129405

test

Habe ich Dietchan gecrasht?
http://imrryr.org/~viktor/ICANN61-viktor.pdf
https://letsencrypt.org/images/blog/ChainofTrust2024CeremonyBlogPost.png

Waren in meinen uploads als die Seite abgestürzt ist, vielleicht nur Zufall und nicht relatiert.

aus gegeben Anlass, d.i die kürzliche Aufdatierung des wohl populärsten Messengerdienstes unter Zockern, welcher nun seinen Shop lüftet, stößt Felix mal den Faden bevor er ihn durchstöbert.

>>129314
see >>129331

i want to keep my barely populated, pseudo intellectual elitism larping board as it is and my boredom shit post spamming board separated.

Activity, just for the sake of activity, can stay on kohl.

Also,
posters who can't even find the officially shilled backup board shouldn't be helped nor encouraged to visit other boards.

>>129331
The real problem is that someone thought it would be a good idea to make a JSON list of all imageboards, which makes life very easy for professional spammers.