Cairo-Dock unter Gnome und Cinnamon betreiben

Eye Candy ist immer wieder ein Thema bei Linux, denn man kann es ja auch mal schön haben wollen, statt immer nur Konsole sehen zu müssen 😉
Eins der Must-Haves ist dann wohl Cairo-Dock, daß bei Fedora per DNF nachinstallierbar ist. Zusammen mit Cinnamon und Gnome, sieht das alles dann schon richtig gut aus.

Wer Eye Candy auf seinem Desktop/Laptop bevorzugt , z.B. um Windowsuser blass werden zu lassen, wie cool doch der Nicht-Apple so aussehen könnte 😉 der findet in Cairo den richtigen Partner.
Cairo-Dock ist nur ein Dock, also kein Windowmanager und damit kann man es unter Gnome-Cinnamon-Xfce usw. einsetzen.

Die Vielfalt an Effekten ist erweiterbar, aber auch schon so der Hammer. Was ein bisschen blöd voreingestellt ist, sind die Abmaße des Docks, aber das läßt sich leicht anpassen. Die Konfigurationsoberfläche ist mannigfaltig mit Optionen ausgestattet, so daß man da ganz leicht den Überblick verlieren kann:

Probleme gibt es eigentlich nur mit der Positionierung, wenn neue Bildschirmkonstellationen zusammen  kommen, da zickt es ein bisschen, aber am Ende klappt auch das. Wie man sehen kann, hat jemand vergessen, daß Konfigtool richtig zu layouten, aber wer sieht das schon dauernd 😀 Unter Cinnamon war es einfacher das Dock an die richtige Stelle zu bekommen, als mit Gnome, dafür ist Gnome schneller.

Nachdem ich 2 Stunden lang damit rumgespielt habe, kann ich sagen, daß wenn ich jetzt noch einen Monitor im MacDesign hätte, das wohl bei mir im Dauereinsatz wäre. Wobei der Rechner dann im Foyer stehen würde, hinter Glas, damit den jeder sieht 😉

Miele Geschirrspüler mit Directory Travelsal Attack

Wie  The Register berichtet, hat Miele einen Industrie Geschirrspüler „Professional PG 8528“ mit Netzanschluß auf den Markt gebracht. Wie nicht anders zu erwarten, patzte der Hersteller bei der Sicherheit ( Was war das doch gleich ? )  und baute ein Netzwerkmodul mit Directory Travelsal Attack Schwachstelle im mitgelieferten Webserver ein.

Es kam wie es kommen mußte, jemand hat mal nachgeschaut und wie auch schon bei anderen IoT Schwachstellenberichten, hat Miele bislang nicht auf die Meldung des Finders der Lücke, Jens Regel von der Firma Schneider-Wulf, reagiert. Auf Updates und Bugfixes werden wir ohne verzichten müssen.

Das Vulnerability Advisory wurde dann auch über die Full Disclosure Mailingliste versendet, so daß jetzt jedes Restaurant, daß die Maschine ordnungsgemäß ins Netz gehängt hat, darauf warten kann, wann der Geschirrspüler das nächstgelegene Wifi hackt oder Spams versendet 😀 Und das alles, weil jemand vom PC aus nachsehen will, ob die rote BetriebsLED am Gehäuse auch funktioniert 😀

All Hail IoT!

 

Update: Miele hat sich dann doch noch gemeldet, nachdem Heise Security nachgefragt hat. „Äh ja, können wir uns auch nicht erklären….usw. usw.“

Achtungserfolg für Samsung Smartphonekamera :)

Einen kleinen Achtungserfolg hat meine Handycam letzte Nacht hingelegt. Obwohl nicht zu erwarten war, daß es auch nur den Hauch einer Chance gibt, hat es das J320F geschafft, etwas am Sternenhimmel abzulichten.

Ja, Ihr müßt das Bild in Groß aufmachen, sonst sieht man nichts 🙂

Natürlich ist das nichts im Vergleich zu einer richtigen Kamera:

Beide Bilder zeigen den (nicht den gleichen) Nordsternhimmel am 26.3.2017, aufgenommen gegen 22:45 Uhr in der Nähe des Havelkreises auf einem Autobahnrastplatz. Mein Bild kommt vom Smartphone, das andere von der Sony Alpha 6000 meiner Freundin. Die das auf Stativ mit einer 4k Auflösung mit ISO 1000 und einem 180Grad Objektiv angenommen hat. Da kommt mein HDR per Hand natürlich nicht mit 😉 Aber immerhin, 2 Sterne waren drauf. Das ist im Vergleich soviel, wie man in Braunschweig 2 Stunden später mit bloßem Auge sehen konnte 😉

Also wer mal wieder einen klaren Sternenhimmel bewundern will, der fährt ins Havelland.

 

Redhat patcht 6 Monate nach Fedora

Wer heute die Patchnotes der CERTs verfolgt hat, wird dort eine Warnung für BASH finden, die vom Redhat Security Team stammt.

Betroffene Software:

  Bash
  

Betroffene Plattformen:

  Red Hat Enterprise Linux Desktop 6
  Red Hat Enterprise Linux HPC Node 6
  Red Hat Enterprise Linux Server 6
  Red Hat Enterprise Linux Workstation 6
  
Mehrere Schwachstellen in GNU Bash ermöglichen einem lokalen, nicht
authentisierten Angreifer die Ausführung beliebigen Programmcodes, auch mit
Administratorrechten, sowie das Umgehen von Sicherheitsvorkehrungen u.a. mit
der Folge eines Denial-of-Service (DoS)-Zustandes.

Red Hat stellt für die Red Hat Enterprise Linux 6 Produkte Server, Desktop,
Workstation und HPC Node Sicherheitsupdates bereit.

Patch:

  Red Hat Security Advisory RHSA-2017:0725

  <http://rhn.redhat.com/errata/RHSA-2017-0725.html>

Da es sich hier um eine aus meiner Sicht problematische Sicherheitslücke handelt, ist es unverständlich, wieso RedHat 6 Monate gewartet hat. Fedora, daß ja im Prinzip vom selben Team mit betreut wird, hatte den Patch bereits im September 2016 eingepflegt:

* Fr Sep 30 2016 Siteshwar Vashisht <svashisht@redhat.com> - 4.3.42-7
- CVE-2016-7543: Fix for arbitrary code execution via SHELLOPTS+PS4 variables
  Resolves: #1379634

* Mi Sep 21 2016 David Kaspar [Dee'Kej] <dkaspar@redhat.com> - 4.3.42-6
- CVE-2016-0634 - Fix for arbitrary code execution via malicious hostname
  Resolves: #1377614

Für mich erschreckend daran, daß die Lücke auch nur als Moderate geführt wird, obwohl man mit Hilfe eines DHCP Servers Code auf einem Computer ausführen kann. Einen Rouge DHCP Server in ein Netz zu bringen ist nachdem man einen Computer übernommen hat, nicht mehr so schwer. Da die meisten Netze via DHCP gemanaged werden, reagieren natürlich auch praktische alle Rechner im Netz auf so einen Angriff. Um so mehr ist es unverständlich, wie es sechs Monate gedauert hat, bis der Patch endlich erstellt wurde.

Und dabei hatte ich vor, die Linux Distributionen für Ihre zügigen Updates zu loben, was zumindest bei Fedora stimmt.

Wie man rausbekommt, wer ausgeswappt wurde

Wir kennen es alle, Zig GB Ram in Hardware verbaut und die Kiste swappt trotzdem. Da will man irgendwann wissen, wer/welcher Prozess dafür verantwortlich ist. Aber der Reihe nach:

Was ist „Swappen“ ?

Dazu müssen wir erstmal wissen, was virtuelles Ram ist. Physikalisches Ram kann sich sicher jeder vorstellen, das kann man als Baustein in die Hand nehmen 😉 Selbiges ist z.b. 10 GB groß ( siehe unten / nicht fragen ist ne VM )

top - 16:26:05 up 17:16,  1 user,  load average: 0,75, 0,56, 0,53
Tasks: 413 total,   1 running, 411 sleeping,   0 stopped,   1 zombie
%Cpu(s):  8,3 us,  4,0 sy,  0,0 ni, 86,5 id,  0,4 wa,  0,4 hi,  0,1 si,  0,2 st
KiB Mem : 10264728 total,   563348 free,  3256528 used,  6444852 buff/cache
KiB Swap:  1048572 total,   739584 free,   308988 used.  6788296 avail Mem

d.b. „physikalisch“ stehen allen Programmen zusammen maximal 10 GB Hauptspeicher zur Verfügung, mit dem sie auskommen müssen. Wenn alle RAM Speicherzellen benutzt werden und jemand will mehr Speicher haben, gibt es einen OOM Error : Out Of Memory! und die Aktion schlägt fehl, was Programme üblicherweise übel nehmen und die weitere Zusammenarbeit verweigern. Soweit, so klar.

Jetzt gibt es aber Programmierer, die mehr Speicher anfordern, als ihre Anwendung braucht. Der RAM wird „nutzlos“ belegt und steht anderen Programmen nicht zur Verfügung. Entweder müßte man GB weise Ram nachrüsten, oder man tut nur so als wenn man Speicher hätte 🙂

Virtueller Speicher

Auch VMEM genannt, ist nichts anderes als die Illusion, daß man mehr Speicher hat, als man hat. Technisch gesehen ist, das einfach: Bevor ein Programm nichts in den Speicher, den es anforderte, geschrieben hat, muß es den Speicher nicht wirklich geben. Man kann dem Programm einfach sagen, daß seine Anforderung nach 10 TB Ram erfolgreich war. Solange es die 10 TB nie benutzt, ist alles ok.

Wird von dem Programm etwas in seinen Speicherbereich geschrieben, so merkt dies das OS und kann den Speicherblock tatsächlich physikalisch machen. Eine MMU ( Memory Management Unit ) in der CPU macht das. Die mapped nämlich den echten Physikalischen Speicherbereich in den Virtuellen Speicherbereich, so daß die Schreibzugriffe an Adressen gehen, die es nicht wirklich gibt, aber so umgebogen werden, daß sie an der richtigen Stelle landen, alles hardwaremäßig.

Das klappt solange, wie der real genutzte Speicher kleiner ist, als die Menge verbauten Hauptspeichers.

Der Notfall: Einen OOM verhindern.

Kurz vor dem Punkt, wo das System keinen Speicher mehr hätte, wird geprüft, wann einzelne Speicherbereiche das letzte mal gelesen oder geschrieben wurden. Wenig verwundernd stellt man dann fest, daß es Speicherblöcke gibt, die in letzter Zeit nicht benutzt wurden.

Idee: Die könnte ich doch irgendwo in einem langsamen Speichermedium mit viel Platz auslagern, oder ? Gedacht, getan: Das Swappen wurde aktiviert und meint, daß bei Speichermangel ungenutzte Teile auf die Festplatte geschrieben werden und andere Teile, die dort schon lagen, wieder eingelesen werden. Man tauscht(swap) also die aktiven und inaktiven Speicherbereiche mit Hilfe der Platte aus.

Swappen

Dieser Vorgang heißt „swappen“. Es wird also ständig auf die Platte geschrieben und davon gelesen. Das hört sich erstmal nicht nach einem Problem an. Ist es aber, weil wenn soviel verschiedenes RAM ständig geswappt wird, wird das System langsam, schliesslich muß man warten bis dieser Vorgang vorbei ist. Wenn es langsam wird, stauen sich die Prozess: Die Load/Last steigt.

Die Idee beim Swapspeicher ist, daß man lange ungenutzte Speicherblöcke auslagert und die auch nicht gleich wieder benutzt werden. Auf einem Desktoprechner ist der Klassiker, daß der Speicher frei ist, bis Photoshop ein 50MP Bild lädt. Das geht vielleicht noch ins RAM, aber Browser, Mailprogramm, Kalender usw. nicht mehr. Da man aber gerade mit Photoshop arbeitet, ist das auch nicht schlimm, denn es ist nicht zu erwarten, daß ich vor Beendigung der aktiven Aufgabe von Photoshop eins der anderen Programme brauche. I.d.R. klappt das auch. Das führt zur irrigen Annahme, daß viel Swapspeicher = „total geile Sache“ ist.

Auf einem Server ist das etwas anderes. Da kann man nicht wirklich vorhersehen, wann ein Dienst gebraucht wird und da ist swappen zu vermeiden. Weil wenn viel Swapspeicher vorhanden ist, dauert es auch entsprechend lange, bis der voll beschrieben oder gelesen ist. d.h. der Rechner steht praktisch, nur weil er Speicher auf die Platte schreibt.

Auf einem Server ist es deutlich cleverer, wenig Swapspeicher zu haben, damit tatsächlich ein OOM entsteht, wenn es nötig ist. Kleinere temporäre Swaps sollten aber möglich bleiben. Deswegen ist der Swapspeicher im Beispiel oben auch nur 1 GB groß. Die Regel, daß der Swap 50% vom Hauptspeicher groß sein sollte, war im MB Bereich charmant, mit GB aber nicht mehr ganz so gut.

Wie verhindert man das Swappen ?

Mal davon abgesehen, daß man das Abschalten und auch das Verhalten des Swappens im Kernel beeinflussen kann, wäre es viel cleverer den Grund für das Swappen zu finden und das geht nur, wenn man weiß wer gerade geswappt wird.

Bevor die Kommentare losgehen: Das Programm, dessen Speicher auf dem Swapspeicher landet, muß nicht jenes sein, daß zuviel RAM wollte. Aber es ist das Programm auf das man am ehesten verzichten kann 😉 Das es überhaupt im Swap gelandet ist, beweist, daß es nicht aktiv war/ist und deswegen müßte man mal nachdenken, ob man es überhaupt braucht. Dazu muß man aber erstmal wissen, wer da gelandet ist.

SMEM – die Speicheranzeige

SMEM ist ein Tool, daß man sich per DNF nachinstallieren muß. Es produziert so eine Map :

  PID User     Command                         Swap      USS      PSS      RSS 
  557 root     /sbin/rngd -f                    156        4        7     1292 
  752 root     /sbin/agetty --noclear tty1      128        4       12     1692 
  753 root     /sbin/agetty --keep-baud 11      152        4       35     2184 
 1690 mailman  /usr/bin/python /usr/lib/ma    30000        4       51     1676 
  614 root     /usr/sbin/atd -f                 180       52       66     2104 
18675 root     sleep 60                           0       80       97     1312 
19506 root     sleep 30s                          0       84      126     1736 
 1467 samba    /usr/sbin/smbd                  2048       16      323     2868 
 9514 50779    dovecot/imap                       0      312      340     3828 
 1659 nobody   proftpd: (accepting connect     2076      144      349     2148 
12494 root     dovecot/log                        0      348      355     2544

In der Liste kann man schön sehen, daß Mailman schön hervor sticht. Mailman ist ein Mailinglistenmanager. Den braucht man nur ganz selten. Da müßte man mal über einen Umzug nachdenken. Die Liste oben ist natürlich nur ein Auszug und wenig aussagekräftig. Im weiteren Verlauf tauchte Mailman dann entsprechend oft auf.

Hinweis: DAS ein Programm mal den einen oder anderen Block ausgelagert bekommen hat, ist nicht weiter dramatisch. Das gibts öfter und ist auch kein Problem, weil diese Teile üblicherweise nur beim Start wichtig waren und später einfach nicht mehr benutzt werden.

Wenn man den Verursacher des Speicherverbrauchs sucht, geht man anders vor:

watch -n 1 „top -c -b -n >> /tmp/memory.log“  oder watch -n 1 „smem >> /tmp/memory.log“

Wobei im Einzelfall „-n 1“ vielleicht ein bisschen zu oft ist und man jede Menge ungewollte IO generiert. Da müßt Ihr etwas auf Eure Bedürfnisse achten.

Aus der Ausgabe kann man dann mit AWK den Namen des Programms, den Speicherverbrauch und den Zeitpunkt ermitteln. Ein bisschen Bashmagie und man bekommt schnell mit, wer der Verursacher ist.

Kleines Beispiel auf dem Weg zum eigenen Terminal :

# smem | grep -E " [0-9]{6,} "
3983 root     spamd chil                         0    42344    47397   104600
8016 root     spamd chil                         0    44636    49667   106744
3937 root     spamd chil                         0    44924    49907   106584
4158 root     spamd chil                         0    45352    50354   107176
2033 exim     /usr/sbin/clamd -c /etc/cla      772   497848   498045   501436
14335 mysql   /usr/libexec/mysqld --based        0   853144   853421   858820
4269 nobody   java server/Server                 0  1175172  1175819  1179580

Das gibt einem nur die Zeilen aus, in denen mehr als fünfstellige Zahlen vorkommen, weil den Kleinkram suchen wir ja nicht.

In dem Beispiel oben lohnt sich der Blick auf den Clam AntiVirusprozess clamd. Der verbraucht mittlerweile 750MB RAM nur durch den Start und der größte Block davon ist meistens unbenutzt. Clamd bietet sich als Ziel der Aktion aus deswegen an, weil er Netzwerkfähig ist. Man kann also leicht einen zweiten Server aufbauen, der nur Clamd laufen hat und zu dem alle anderen Server hingehen und Ihre Mails auf Viren checken lassen.

So bräuchte man die 750 MB nicht mehr auf jedem Mailserver verbraten, sondern nur einmal. Natürlich setzt das voraus, daß der Server mit dem Clamd auch schnell etwaige Anfragen beantwortet. Aber das ist ein anderes Thema.

RPM: wie man zusätzliche alte/neue Kernels installiert

Wer Linux benutzt, wird früher oder später mal einen alten Kernel benutzen müssen. Sei es, weil im neuen ein Treiber fehlt, oder obskure Dinge passieren, wo man den Stand von letzter Woche nochmal austesten muß, z.b. als Vergleichsbasis.

Normalerweise behält Fedora die letzten 3 Kernels auf der Platte, besonders der laufende Kernel wird nie gelöscht. Nur, wenn so ein Problem erst Tage später bemerkt wird, kann es sein, daß der alte Kernel weg ist.

Wenn man dann einen alten Kernel gefunden hat, dazu gibt es diverse Möglichkeiten, und man installiert das Paket mit DNF, dann geht das nicht, weil es veraltet ist. Die meisten greifen dann auf RPM direkt zurück, was richtig ist. Wenn man das allerdings als Update einspielt, sind plötzlich alle neueren Kernels weg 🙂

Der richtige Befehl dazu lautet: rpm -ivh –oldpackage …/kernel-der-wahl-*rpm

Falls man es doch schon verbockt hatte, einfach mit DNF den neuesten Kernel wieder installieren 😉

Ein MCP namens SystemD

Bunte Linien kreisen vor meinen Augen und bilden bunte Muster. Die Augen schmerzen. Der Kopf schmerzt und auch das Gehirn hat Schaden genommen. Die Welt ist dunkel, aber bunt.  Ich öffne die Augen. Ein rötlich strahlender Wächter stößt mich mit einer Energielanze an: „Aufstehen, Programm!“ Er will, daß ich mit ihm komme. Wir beschreiten Wege aus Energie… bunter Energie, seltsam neonfarbend und doch schwarz, wie die Nacht. Unterwegs treffen wir andere „Programme“ mit Ihren „Wächtern“. Bald stehe ich vor einem Kopf aus Licht: Der MCP, es gibt ihn wirklich!!!!!!

Verstört wache ich auf. Ein Computeradminalptraum, mitten am Tag, vermutlich am Keyboard eingenickt. Aber was könnte mir so einen Schrecken eingejagt haben, daß ich davon einen Tron .. ähm… traum hatte ?

Es fällt mir wieder ein, ich war grade dabei den Beitrag „Revenge of MariaDB“ Part II zu schreiben. Ja, MariaDB, was war doch gleich … achja.. ging mal wieder nicht nach dem Wechsel von F23 auf F24. Einer unserer Datenbankserver  macht merkwürdige Dinge. Die Webanwendung produzierte sporadisch „Kann nicht in die Datenbank verbinden“ Fehlermeldungen und brachte damit die QA vom Kunden an den Rand des Nervenzusammenbruchs.

Die Analyse geschaltete sich schwierig, weil die Admins immer erst nach einem Vorfall gerufen wurden, aber da ging es wieder. Erst eine zeitnahe Analyse des Netzwerkverkehrs bracht dann den ersten Hinweis: „Can’t create a new Thread. If you have enough free memory, check if … “

Damit konnte man etwas anfangen, ein Blick in eine spezielle Überwachungsdatei brachte dann den Hinweis, daß statt 40.000 Datenbankprozessen, nur wenige Hundert liefen. Also half nur ein Testlauf, mit einer Software, die Verbindungen in die Datenbank aufbaut und offen hält. Sowas kann man schnell in PHP, Perl oder Java schreiben:

import ordb.*;

public class Test {

    public static void main(String[] args) {

        Httpd[] liste = new Httpd[100000];
        for(int i=0;i< Integer.parseInt( args[0] );i++) {
            System.out.println("i="+i);
            liste[i] = new Httpd();
        }
        try {
            Thread.sleep(30000);
        } catch(Exception e) {

            e.printStackTrace();
            System.out.println(e);
        }

    }

}

In einer zweiten Konsole, kann man dann den Datenbankserver überwachen :

strace -e send,read,write -s 1024 -f -p `pidof mysqld`

Damit hat man alle Datenbankserverinstanzen im Blick, was die so Lesen und Schreiben und tatsächlich bestätigte dies den Anfangsverdacht, daß der Datenbankserver nicht genug Prozesse spawnen kann. Er setzte bei 512 Prozessen aus, viel zu wenig für unsere Anwendung.

Der schwierige Teil : Limits prüfen

Als erstes denkt man natürlich, daß sich bei den Limits aus Systemd und die Limits : The Revenge of Mariadb etwas geändert hätte, hatte es aber nicht. Wenn man das OS updatet können aber noch ganz andere Dinge passieren, also muß man hier nach „neuen“ Limits suchen.  Um überhaupt die Limits eines Prozesses Live einsehen zu können, muß man ins /proc/ eintauchen:  cat /proc/`pidof mysqld`/limits

Das kann dann so aussehen:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            unlimited            unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             unlimited            unlimited            processes 
Max open files            65536                65536                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       32195                32195                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

Dummerweise sagt dies genau, was man nicht hören will: Alles ok, es gibt keine Limits bei den Prozessen.

Und jetzt steht man da, wo zum Geier kommt dieses 512 Prozesse Limit her?

Es gibt eine Datei namens:  /etc/security/limits.conf

In der könnte man Limits für User eintragen, was aber nicht der Fall war. Außerdem wäre das in der Auflistung genau dieser Limits aufgefallen. Wo kommt dann das Limit her ?

An der Stelle muß man dann praktisch zu Denken anfangen, weil Docs lesen bringt einen fast nicht weiter, weil man gar nicht damit rechnet, daß es noch mehr Limitmöglichkeiten gibt, also auch nicht weiß in welcher Richtung man suchen sollte. Ein gesunder Pragmatismus ist jetzt hilfreich, vielleicht wars auch eine Verzweiflungstat :  grep -r 512 /etc/ /proc/sys/

Also in allen Dateien von ETC und PROC nach einer EIntragung mit 512 zu suchen. Und genau das hat zum Erfolg geführt, so daß ich jetzt eine Anklage wegen Ruhestörung und einen Abdruck meiner Hand an der Stirn habe 😀

Der SystemD macht mehr als er sollte

Im SystemD gibt es eine Konfigurationsdatei : /etc/systemd/system.conf

Der Auslieferungszustand bei Fedora ist, daß dort alle Werte auskommentiert sind, also ungültig sind. Dort fand sich eine 512 Eintragung und der Name der Option war … DefaultTasksMax=512 !

Aber die Option war abgeschaltet, also ist doch die erste Annahme, daß es kein Limit gibt, oder? Tja, Pech gehabt! Der Wert ist nur Deko, weil als Default in den SystemD einkompiliert 🙁

Zum Glück kann man den Wert in dieser Config ändern, den SystemD + MariaDB neustarten und dann wird der neue, unlimitierte Wert auch übernommen. Er taucht in keiner ( mir bekannten ) Procdatei auf. (Hinweise willkommen)

Alles in allem eine Änderung die wohl zu einer heftigen Reaktion seitens der Betroffenen geführt hat, weil die Systemd Entwickler das in einer neueren Version auf 15% der möglichen Prozesse eines Systems limitiert haben. In  unserem Fall wäre das noch schlimmer gewesen, weil wir so noch schlechter hätten Debuggen können, weil es sehr viel seltener passiert wäre.

Warum gibt es das Limit überhaupt ? Ja, weil es Bomben gibt. Das sind z.b. Bashscripte die sich selbst starten und dabei von der Shell abforken, so daß nach kurzer Zeit alle Resourcen eines Systems aufgebraucht sind. Hackt man also einen Server, könnte man den so intern dosen. Damit das nicht geht, gibt wenigstens ein Limit 😉 Das mal jemand Fedora als Server benutzt und dann auch noch als High Performance, damit hatte wohl niemand gerechnet 😀

Meiner Meinung nach, sollte sich der SystemD auf das Starten von Programmen konzentrieren, denn da ist er bedingt besser als SystemV. Aber die ganzen anderen Anmaßungen die das Teil so vornimmt, sind nicht so schön. Der SystemD kann einen echt fertig machen 😉

Ich bin mal gespannt, was beim nächsten OS Upgrade auf uns wartet 😉