Beiträge von whoami0501

    Plural von Status ist Status ;)

    Weder Stati noch Statis.

    Was zum... ^^ das habe ich vor x Jahren mal bei der Jugendfeuerwehr gelernt, "die Funkstati der Fahrzeuge"... und hab es seitdem immer benutzt. Du bist der erste der sagt, dass das falsch ist. Okay, der Duden sagt es auch, aber den hatte ich bisher nie zu Rate gezogen. :D

    Hat sich auch erledigt. Ich dachte, dass der Node Exporter keinen Collector für Zombie Prozesse mitbringt. Tut er aber, indem er immer eine Anzahl an Prozessen in allen Statis (I, S, R, D, Z, ....) anzeigt. Der Punkt ist, dass er immer nur die Stati anzeigt, wo grad Prozesse von da sind. Statis mit 0 Prozessen werden nicht angezeigt. ^^ Und da man ja selten Zombies aufm System hat... joa, sieht man das halt nicht gleich. :P

    Sicher könnte bzw. wird es da irgendwo eine Änderung im Kernel gegeben haben, aber man liest halt nirgendwo was davon. Ich zumindestens nicht...

    Man hat doch Co-Admins, die man zum Changelog lesen versklaven kann. Danke nochmal. ^^


    Jener ist mittlerweile bei den Änderungen im Kernel 4.11 fündig geworden. Da wurde einiges am Swap-Modul gemacht, was das von vmk beschriebene Verhalten theoretisch auch erklären würde. Hier gibt es einen Heise Artikel dazu.


    Vermutlich also kein Bug, sondern ein Feature. ^^

    Deine Quelle bezieht sich auf RHEL 6 mit Kernel 2.6.32 aus dem Jahr 2009 mit der expliziten Einschränkung nur gültig bis RHEL 6.3. Wieso diese Einschränkung? Um 2013 gab es Umbauarbeiten im Kernel 3.14 und RedHat hat diese zurückportiert auf den alten Kernel.


    Quelle RedHat: https://access.redhat.com/solutions/3367

    Quelle Kernel: https://kernelnewbies.org/Linu…ness%29#Memory_management

    Okay. Mein Fehler.


    Nagut, ich werde das Verhalten wohl zunächst mal so akzeptieren müssen. Wie gesagt, das mag ja alles seine Gründe haben, macht auch Sinn. Aber es wundert mich trotzdem, dass sich das Verhalten im Gegensatz zu Stretch geändert hat. Sicher könnte bzw. wird es da irgendwo eine Änderung im Kernel gegeben haben, aber man liest halt nirgendwo was davon. Ich zumindestens nicht...

    Moment mal. Ja, es sind nur etwas über 100MB frei, aber zur Verfügung steht doch wesentlich mehr.

    Aber es kann doch nicht sein, dass laufende Programme auslagern, um Platz für den Cache zu machen. Oder doch?

    Systeme sollten meines Wissens nur im absoluten Notfall swappen, zumal sich da ja dann auch die SSD und die allgemeine Performance bedankt...


    Und um den Zeitpunkt vom Eintritt des swappens zu setzen, konfiguriert man die swappiness. Und hier steht geschrieben, dass bei einer swappiness von 0 das Swappen deaktiviert ist. Logisch, denn es ist ja der prozentuale Wert des verfügbaren RAMs. Und 0 würde dann heißen, geh bis ans Limit.

    Selbst wenn man die Swappiness am freien RAM und nicht am verfügbaren RAM ansetzen würde, dann würde es zwar erklären, warum er swappt, aber dann wäre das ganze in meinen Augen sinnentstellt, denn es wird i.d.R. ja immer soviel in den RAM Cache gepackt, wie möglich. Und dann würde er ja immer swappen.


    Swap I/O habe ich leider nicht in meinem Monitoring drin, aber das überarbeite ich allgemein gerade.

    Es ist schon richtig, dass die Prozessteile primär ungenutzt sind und ich schätze mal, dass der besagte I/O auch nicht groß ist. Aber Fakt ist, dass das bisher unter Stretch so nicht passiert ist, und wenn man dann so einen Prozessteil benötigt, dann wird die Sache halt auch schnell mal ganz schön träge...


    Ich kann deinen Denkansatz verstehen, aber warum trat dieses verhalten dann unter Stretch nicht auf? Immerhin waren manche Prozesse da genauso ungenutzt, daran hat sich nichts geändert...

    Was liegt denn nun im Swap? So ist das nur ein Rätselraten ohne Chance.


    Von allem ein bisschen, würde ich sagen.... :/

    swap.py

    Das ist unnormal. Nach dem Buster Update am Sonntag ging meine RAM Nutzung erstmal ordentlich runter, und dann etwas später fing er mit diesem übelsten Swappen an... man sieht auch, dass ich heute mal ein swappoff -a && swapon -a gemacht habe, aber wie man sieht ohne viel Erfolg.

    swap_mem.png

    Langsam gipfelt das hier in Realsatire. Weil mir das ganze auf den Keks ging, habe ich die swappiness auf meinem NAS auf 0 gesetzt und danach nochmal swapoff -a && swapon -a gemacht. Der Swap war an dieser Stelle auch leer, habe ich überprüft.

    Eine paar gzip Kompressionen später und nach noch ein paar anderen Sachen, kam ich dann an folgender Situation raus:

    swap_realsatire.png


    Sorry, aber das widerspricht in meinen Augen jeglicher Logik... das kann doch nur ein Bug sein. :/

    Naja. Ich würde schon bei meiner Position bleiben. Sowohl der HTPC meines Vaters (Athlon 200GE), als auch mein NAS/Homeserver (Celeron J4105) laufen auf ITX Boards von ASRock. Das funktioniert schon, und ich hatte bisher auch nie Probleme.


    Aber wenn ichs halt mit meinem Gigabyte Board aus meinem normalen PC vergleiche, ist ASRock halt nur so billiger Ottonormalkrempel. Glaube nicht, dass ich mir damit einen Gaming PC oder ne fette Workstation bauen wollen würde.

    sollten USB Devices nicht abgeschirmt sein, sodaß derartiges vermieden wird?

    wobei ich kann mich erinnern, daß das Vorbeigehen mit einem Phone an einer E-Lok

    während man telephonierte die Verbindung kappte ...;)

    Das ist halt die Frage... dachte ich mir eigentlich auch.

    Aber wer sagt denn sicher, dass es am Kabel liegt? Die Buchsen sind direkt neben dem WLAN Antennen, und es ist zudem noch ein mITX Board, wo eh alles schon etwas enger zu geht. Und es ist von ASRock, nicht gerade der Premiumhersteller für Boards. So viel dazu...


    Ich befürchte irgendwie, dass das Problem irgendwo innen an den Anschlüssen oder der Platine liegt... kann man nur schwer genau sagen.

    Also sowas ist mir auch noch nicht untergekommen...

    Unter Umständen kann einem das anstecken eines USB3.0 Gerätes an den PC die komplette WLAN Verbindung eliminieren. Ich hatte die Situation gerade, immer wenn mein Vater seine externe an seinen neuen PC steckte, hats die im MoBo integrierte WLAN Einheit komplett in die Knie gezwungen. Nicht mal mehr einfache Websites haben geladen.:/


    Komplett überstürzt, an was das nun wieder liegen mag, bin ich bei Heise auf diesen Artikel gestoßen. Und zwar funkt WLAN bekanntlich (auf längere Distanz) auf dem 2,4GHz Band, so auch in diesem Fall. USB3.0 überträgt seine Daten mit 2,5GHz. Also liegen die Bänder sehr nah aneinander, was das Risiko einer Überlagerung mit sich bringt. Und so ists in meinem Fall auch geschehen. Ich habe mich dann mal über die Kanalfrequenzen von 2,4GHz WLAN informiert, und habe festgestellt, dass Kanal 1 mit 2412MHz am weitesten von USB3.0 weg liegt. Also habe ich den an meiner FritzBox mal eingestellt - und siehe da, alles funktioniert normal. Auch mit Festplatte.

    Also Sachen gibts, die gibts garnicht... komm da erstmal drauf... ^^

    whoami0501 wieso TCP? WireGuard ist UDP only, und ohne weiteren Tunnel bekommst du das nicht durch TCP durch, es sei denn du werkelst ein wenig an der Userspace Implementierung wireguard-go herum.

    Warum TCP? Weil unsere Berufsschule und Seminarstandorte sowas wie Firewalls für ausgehenden Traffic geil finden... *augenroll*


    Mir ist klar, dass WireGuard UDP only ist, daher suche ich eine Lösung im eben den UDP Traffic durch TCP zu tunneln. Aber halt eine möglichst Plattform bzw. OS unabhägngige Variante, die dann auch so ziemlich überall funktioniert... und da strande ich halt aktuell. :(

    Hat hier rein zufällig irgendjemand eine WireGuard Instanz laufen, die er sich über 443/tcp erreichbar gemacht hat?
    Ich habe einen Weg per udptunnel gefunden, aber das hilft einem auch nicht wirklich, weil man damit unter Windows und unter Android halt strandet... Gut, unter Windows gibts noch TunSafe. Aber damit hat man immer noch keine Lösung für Android. Um garnicht erst an den Mac meiner Co-Admina zu denken. :pinch:


    Ich bin echt ratlos, aber ich habe auch keine Lust, jetzt wieder mit OpenVPN anzufangen... miese Briese... :(

    Bei Debian ist das ohne Probleme möglich. Firewalld hat seit der Version 0.6.x support für nftables.


    /etc/firewalld/firewalld.conf

    Code
    FirewallBackend=nftables

    So, ich probiere das ganze gerade mal bei meinem NAS aus. Aber jetzt bin ich beim Routing ins VPN angekommen und da strande ich. Ich glaube, ich muss das doch eher alles per nftables von Hand machen. Naja, erstmal in Ruhe anschauen den Kram... ^^

    Hat hier evtl. schon jemand einen seiner Server auf nftables umgestellt und mag mal seine Firewall Config bzw. Regeln bzw. Script teilen? Ich schau da einfach nicht durch, ich bräuchte echt mal ein gutes Beispiel, an dem man sich orientieren kann. ^^

    Ich habe es jetzt nur mal angeschaut, nicht richtig ausgetestet, aber es wirkt echt gut. :)


    Nur das irgendwelches Google Gedönse eingebunden ist, stört mich. Aber dafür hat man ja uBlock Origin.


    Kleinkram: Impressum und Rechtliches, Punkt 2: "folgene Punkte" :P