Zum Inhalt springen

Cgroups: Unterschied zwischen den Versionen

Aus Foxwiki
Die 5 zuletzt angesehenen Seiten:  Maximum Transmission Unit » IRIX » PuTTY/puttygen » Let's Encrypt/LAN » cgroups
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
Visuell
K Textersetzung - „line>“ durch „line copy>“
 
(26 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''cgroups''' - Ressourcenkontrolle unter Linux
'''cgroup''' - Ressourcenkontrolle unter Linux
 
'''topic''' - Beschreibung


== Beschreibung ==
== Beschreibung ==
Mit '''cgroups'''- lassen sich Ressourcen von Prozessen beschränken


== Installation ==
; Ressourcensteuerung und -kontrolle umsetzen
<syntaxhighlight lang="bash" highlight="1" line>
Genutzten Arbeitsspeicher eines einzelnen Prozesses oder einer Gruppe von Prozessen beschränken
</syntaxhighlight>
 
== Aufruf ==
<syntaxhighlight lang="bash" highlight="1" line>
</syntaxhighlight>
 
=== Optionen ===
{| class="wikitable sortable options gnu"
|-
! Unix !! GNU !! Parameter !! Beschreibung
|-
| || || ||
|-
|}
 
=== Parameter ===
 
=== Umgebungsvariablen ===
 
=== Exit-Status ===
{| class="wikitable options col1center"
|-
! Wert !! Beschreibung
|-
| 0 || Erfolg
|-
| >0  || Fehler
|}
 
== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line>
</syntaxhighlight>
 
=== Problembehebung ===
 
== Konfiguration ==
 
=== Dateien ===
{| class="wikitable options"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
 
=== Dokumentation ===
 
; Man-Page
# [https://manpages.debian.org/testing/procps/pgrep.1.de.html prep(1)]
 
; Info-Pages
 
=== Links ===
==== Projekt ====
 
==== Weblinks ====
 
 
{{DEFAULTSORT:new}}
{{DISPLAYTITLE:new}}
 
[[Kategorie:systemd]]
 
</noinclude>
 
= TMP =
=== Beschreibung ===
Mit dem neuen Cgroups-Feature lässt sich bei modernen Linux-Distributionen der Ressourcen-Verbrauch etwa von Prozessen administrativ beschränken
* Besonders interessant ist die Anwendung der Technologie bei virtualisierten Systemen
 
Vor einigen Jahren führte der Autor eine Linux-Schulung bei einem großen IT-Dienstleister durch
* Dessen Administratoren verfügten über umfangreiche Erfahrungen mit kommerziellen Unix-Varianten, wie etwa HP-UX, und stellten die Frage, wie sie unter Linux eine Ressourcensteuerung und -kontrolle umsetzen könnten:
 
Wie kann ein Administrator den genutzten Arbeitsspeicher eines einzelnen Prozesses oder einer Gruppe von Prozessen beschränken?
 
Zum damaligen Zeitpunkt musste der Autor einräumen, dass Linux diese Funktion nicht bietet. 2006 hat jedoch Rohit Seth begonnen, diese Funktionalität zu entwickeln
* Seit dem Kernel 2.6.24 kann ein Administrator diese nun auch nutzen


Ursprünglich als "process container" bezeichnet, können die Control-Groups (kurz: cgroups) Ressourcen (Arbeitsspeicher, CPU, I/O) limitieren, priorisieren, zählen (für Abrechnungszwecke) und isolieren
Ursprünglich als "process container" bezeichnet, können die Control-Groups (kurz: cgroups) Ressourcen (Arbeitsspeicher, CPU, I/O) limitieren, priorisieren, zählen (für Abrechnungszwecke) und isolieren


Auch wenn viele Administratoren diese Funktionalität auf einem normalen Server wahrscheinlich nicht einsetzen werden, ist sie beim Einsatz etwa von KVM-Virtualisierung sehr interessant
Beim Einsatz etwa von KVM-Virtualisierung sehr interessant
* Mit Cgroups lassen sich die Ressourcen eines virtuellen Gastes beschränken oder gegenüber anderen Gästen priorisieren
* Mit Cgroups lassen sich die Ressourcen eines virtuellen Gastes beschränken oder gegenüber anderen Gästen priorisieren


=== Gruppenzwang ===
== Gruppen ==
 
Mit einer '''cgroup''' können mehrere Prozesse zu einer Gruppe zusammenfasst werden
Mit einer Cgroup kann ein Administrator mehrere Prozesse zu einer Gruppe zusammenfassen
* Diese Prozesse und sämtliche Kindprozesse kann dann mit Parametern für bestimmte Subsysteme versehen
* Diese Prozesse und sämtliche Kindprozesse kann der Administrator dann mit Parametern für bestimmte Subsysteme versehen
* Ein Subsystem ist dann etwa ein Ressource-Controller, der den verfügbaren Arbeitsspeicher verwaltet
 
Ein Subsystem ist dann zum Beispiel ein Ressource-Controller, der den verfügbaren Arbeitsspeicher verwaltet
* Am einfachsten illustriert dies ein Beispiel


Um die Cgroups zu verwenden, muss der Administrator zunächst Hierarchien anlegen, in der die Gruppen verwaltet werden
; Beispiel
Um die Cgroups zu verwenden, muss zunächst Hierarchien anlegen, in der die Gruppen verwaltet werden


Hierzu editiert er die Datei ''<tt>/etc/cgconfig.conf</tt>'' , die in [http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux#article_l1 Listing 1] zu sehen ist
Hierzu editiert er die Datei ''<tt>/etc/cgconfig.conf</tt>'' , die in zu sehen ist
* Existiert die Datei noch nicht, so muss er das entsprechende Paket noch installieren
* Existiert die Datei nicht, so muss er das entsprechende Paket noch installieren


Diese Datei legt für jedes Subsystem eine eigene Hierarchie an, unterhalb derer die Cgroups angelegt werden können
Diese Datei legt für jedes Subsystem eine eigene Hierarchie an, unterhalb derer die Cgroups angelegt werden können
* Die Hierarchie ''<tt>/cgroup/cpu</tt>'' erlaubt die Verwaltung der CPU-Shares, während ''<tt>/cgroup/net_cls</tt>'' die Verwaltung der Netz-I/O-Leistung unterstützt
* Die Hierarchie ''<tt>/cgroup/cpu</tt>'' erlaubt die Verwaltung der CPU-Shares, während ''<tt>/cgroup/net_cls</tt>'' die Verwaltung der Netz-I/O-Leistung unterstützt


Listing 1
; /etc/cgconfig.conf
 
<syntaxhighlight lang="bash" highlight="1" line copy>
/etc/cgconfig.conf
 
01 mount {
01 mount {
02 cpuset = /cgroup/cpuset;
02 cpuset = /cgroup/cpuset;
Zeile 128: Zeile 39:
10 blkio = /cgroup/blkio;
10 blkio = /cgroup/blkio;
11 }
11 }
</syntaxhighlight>


; Cgroups-Dateisystem
Ein Start des Cgconfig-Daemons erzeugt dann die Verzeichnisse und mountet das Cgroups-Dateisystem
Ein Start des Cgconfig-Daemons erzeugt dann die Verzeichnisse und mountet das Cgroups-Dateisystem
* Mit dem Befehl ''<tt>lssubsys</tt>'' kontrolliert der Admin die korrekte Erzeugung der Hierarchien ([http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux#article_l2 Listing 2])
Listing 2


Mit dem Befehl ''<tt>lssubsys</tt>'' kontrolliert der Admin die korrekte Erzeugung der Hierarchien
<syntaxhighlight lang="bash" highlight="1" line copy>
lssubsys
lssubsys
01 # lssubsys -am
01 # lssubsys -am
02 cpuset /cgroup/cpuset
02 cpuset /cgroup/cpuset
Zeile 146: Zeile 57:
09 ns /cgroup/ns
09 ns /cgroup/ns
10 blkio /cgroup/blkio
10 blkio /cgroup/blkio
</syntaxhighlight>


Die Control Groups legt der Administrator mit dem Befehl ''<tt>cgcreate</tt>'' an:
; Control Group anlegen
 
<syntaxhighlight lang="bash" highlight="1" line copy>
cgcreate -g blkio:/dd
cgcreate -g blkio:/dd
</syntaxhighlight>


Welche Parameter für das Subsystem Block-I/O zur Verfügung stehen, lässt sich mit dem Befehl in [http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux#article_l3 Listing 3] in Erfahrung bringen
; Block-I/O-Subsystem
 
Parameter für das Subsystem Block-I/O
Listing 3
<syntaxhighlight lang="bash" highlight="1" line copy>
 
sudo cgget -g blkio /dd
Block-I/O-Subsystem
/dd:
 
blkio.reset_stats=
01 # cgget -g blkio /dd
blkio.io_queued=Total 0
02 /dd:
blkio.io_merged=Total 0
03 blkio.reset_stats=
blkio.io_wait_time=Total 0
04 blkio.io_queued=Total 0
blkio.io_service_time=Total 0
05 blkio.io_merged=Total 0
blkio.io_serviced=Total 0
06 blkio.io_wait_time=Total 0
blkio.io_service_bytes=Total 0
07 blkio.io_service_time=Total 0
</syntaxhighlight>
08 blkio.io_serviced=Total 0
09 blkio.io_service_bytes=Total 0
10


Ab Kernel 2.6.37 unterstützt der Kernel hier auch die Optionen ''<tt>blkio.throttle.*</tt>''  
Seit der Version 2.6.37 unterstützt der Kernel hier auch die Optionen ''<tt>blkio.throttle.*</tt>''  
* Damit kann der Administrator die maximale I/O-Bandbreite beim Lesen und Schreiben einer Prozessgruppe einschränken
* Damit kann die maximale I/O-Bandbreite beim Lesen und Schreiben einer Prozessgruppe einschränken


Um dies zu testen, benötigt der Admin zunächst die Major- und Minor-Nummern des Gerätes, auf dem die Bandbreite eingeschränkt werden soll
Um dies zu testen, benötigt der Admin zunächst die Major- und Minor-Nummern des Gerätes, auf dem die Bandbreite eingeschränkt werden soll
* Handelt es sich um ''<tt>/dev/sda1</tt>'' , kann er diese mit einem einfachen ''<tt>ls</tt>'' ermitteln:


# ls -l /dev/sda1
Handelt es sich um ''<tt>/dev/sda1</tt>'' , kann er diese mit einem einfachen ''<tt>ls</tt>'' ermitteln:
brw-rw----. 1 root disk 8, 1 10
<syntaxhighlight lang="bash" highlight="1" line copy>
* Okt 08:32 /dev/sda1
sudo ls -l /dev/sda1
brw-rw----. 1 root disk 8, 1 10. Okt 08:32 /dev/sda1
</syntaxhighlight>


Hier handelt es sich um die Major/Minor-Nummern 8 respektive 1
Hier handelt es sich um die Major/Minor-Nummern 8 respektive 1
* Um die Bandbreite für die Control-Group nun auf 1 Mbyte/s zu beschränken, verwendet er den Befehl ''<tt>cgset</tt>'' oder einfach ein ''<tt>echo</tt>'' :
* Um die Bandbreite für die Control-Group nun auf 1 Mbyte/s zu beschränken, verwendet er den Befehl ''<tt>cgset</tt>'' oder einfach ein ''<tt>echo</tt>'' :
 
<syntaxhighlight lang="bash" highlight="1" line copy>
echo "8:1 1048576" > /cgroup/blkio/dd/blkio.throttle.write_bps_device
echo "8:1 1048576" > /cgroup/blkio/dd/blkio.throttle.write_bps_device
</syntaxhighlight>


Für den Test startet er nun dd
Für den Test startet er nun dd
 
<syntaxhighlight lang="bash" highlight="1" line copy>
dd if=/dev/zero of=/tmp/test & pid=$!
dd if=/dev/zero of=/tmp/test & pid=$!
</syntaxhighlight>


Zunächst arbeitet der Prozess ''<tt>dd</tt>'' in der Root-Cgroup, die nicht eingeschränkt ist
Zunächst arbeitet der Prozess ''<tt>dd</tt>'' in der Root-Cgroup, die nicht eingeschränkt ist
* Dies testet der Administrator, indem er dem Prozess ein SIGUSR1 sendet:


# kill -USR1 $pid
; Test
Prozess ein SIGUSR1 senden
<syntaxhighlight lang="bash" highlight="1" line copy>
sudo kill -USR1 $pid
578804+0 Datensätze ein
578804+0 Datensätze ein
578804+0 Datensätze aus
578804+0 Datensätze aus
296347648 Bytes (296 MB) kopiert, 7,00803 s,42,3 MB/s
296347648 Bytes (296 MB) kopiert, 7,00803 s,42,3 MB/s
</syntaxhighlight>


Um den Prozess in die Cgroup ''<tt>dd</tt>'' zu verschieben, verwendet er den Befehl ''<tt>echo</tt>'' :
; In die Cgroup verschieben
Prozess in die Cgroup ''<tt>dd</tt>''verschieben
<syntaxhighlight lang="bash" highlight="1" line copy>
sudo echo $pid > /cgroups/blkio/dd/tasks
</syntaxhighlight>


# echo $pid > /cgroups/blkio/dd/tasks
; Erneutes USR1-Signal
 
* Sendet nun erneut ein USR1-Signal an den ''<tt>dd</tt>'' -Prozess
Sendet der Administrator nun erneut ein USR1-Signal an den ''<tt>dd</tt>'' -Prozess, erkennt er, dass die durchschnittliche Bandbreite stark sinkt, da der Prozess nun nur noch mit einer Bandbreite von 1 MByte/s schreiben darf
* erkennt er, dass die durchschnittliche Bandbreite stark sinkt, da der Prozess nun nur noch mit einer Bandbreite von 1 MByte/s schreiben darf
 
* Statt die maximale Bandbreite zu beschränken, kann der Admin auch die Bandbreiten zwischen den Gruppen priorisieren
Statt die maximale Bandbreite zu beschränken, kann der Admin auch die Bandbreiten zwischen den Gruppen priorisieren


; blkio.weight
Hierzu dient der Parameter ''<tt>blkio.weight=</tt>''  
Hierzu dient der Parameter ''<tt>blkio.weight=</tt>''  
* Der Default-Wert beträgt 500
* Der Default-Wert beträgt 500
* Erhält eine Gruppe den Wert 1000, so kann sie doppelt so häufig auf die Block-Geräte zugreifen wie die anderen Gruppen
* Erhält eine Gruppe den Wert 1000, so kann sie doppelt so häufig auf die Block-Geräte zugreifen wie die anderen Gruppen


; cgclassify
Statt des Echo-Kommandos lassen sich Prozesse auch mit dem Kommando ''<tt>cgclassify</tt>'' einzelnen Gruppen zuweisen
Statt des Echo-Kommandos lassen sich Prozesse auch mit dem Kommando ''<tt>cgclassify</tt>'' einzelnen Gruppen zuweisen


; Prozess direkt in einer bestimmten Gruppe starten
Möchte der Admin einen Prozess direkt in einer bestimmten Gruppe starten, so verwendet er den Befehl ''<tt>cgexec</tt>'' :
Möchte der Admin einen Prozess direkt in einer bestimmten Gruppe starten, so verwendet er den Befehl ''<tt>cgexec</tt>'' :
 
<syntaxhighlight lang="bash" highlight="1" line copy>
cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"
cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"
</syntaxhighlight>


=== Automatik ===
== Automatik ==
 
Die manuelle Zuweisung von Prozessen zu verschiedenen Gruppen ist aufwendig und fehlerträchtig
Die manuelle Zuweisung von Prozessen zu verschiedenen Gruppen ist aufwendig und fehlerträchtig
* Besser ist es deshalb, wenn der Daemon ''<tt>cgrulesengd</tt>'' diese Zuweisung auch automatisch übernimmt
* Besser ist es deshalb, wenn der Daemon ''<tt>cgrulesengd</tt>'' diese Zuweisung auch automatisch übernimmt
* Hierzu benötigt dieser Dienst die Regeldatei ''<tt>/etc/cgrules.conf</tt>'' , die ihm mitteilt, welcher Prozess von welchem Benutzer in welcher Control-Group landen soll
* Hierzu benötigt dieser Dienst die Regeldatei ''<tt>/etc/cgrules.conf</tt>'' , die ihm mitteilt, welcher Prozess von welchem Benutzer in welcher Control-Group landen soll
* Die Datei besitzt eine recht einfache Syntax:
* Die Datei besitzt eine recht einfache Syntax:
 
<syntaxhighlight lang="bash" highlight="1" line copy>
<user>[:<process] <controllers> <destination>
<user>[:<process] <controllers> <destination>
</syntaxhighlight>


Für das Beispiel mit dem ''<tt>dd</tt>'' -Kommando sieht die Regel folgendermaßen aus:
Für das Beispiel mit dem ''<tt>dd</tt>'' -Kommando sieht die Regel folgendermaßen aus:
 
<syntaxhighlight lang="bash" highlight="1" line copy>
*:dd blkio /dd
dd blkio /dd
</syntaxhighlight>


Dies fügt die ''<tt>dd</tt>'' -Prozesse sämtlicher Benutzer der Controlgroup ''<tt>/dd</tt>'' des Blkio-Resource-Controllers hinzu
Dies fügt die ''<tt>dd</tt>'' -Prozesse sämtlicher Benutzer der Controlgroup ''<tt>/dd</tt>'' des Blkio-Resource-Controllers hinzu




=== Hierarchien ===
== Hierarchien ==
 
Bisher betrachtet der Artikel nur einzelne isolierte Control-Groups
Bisher betrachtet der Artikel nur einzelne isolierte Control-Groups
* Zur besseren Strukturierung lassen sich aus Gruppen aber auch
* Zur besseren Strukturierung lassen sich aus Gruppen aber auch


Hierarchien bilden
Hierarchien bilden
* So kann der Administrator innerhalb einer Control-Group weitere Control-Groups anlegen, etwa mit ''<tt>cgreate -g blkio:/dd/user1</tt>''  
* So kann innerhalb einer Control-Group weitere Control-Groups anlegen, etwa mit ''<tt>cgreate -g blkio:/dd/user1</tt>''  


Diese erscheinen dann als Unterverzeichnisse und erben die Eigenschaften der übergeordneten Control-Group
Diese erscheinen dann als Unterverzeichnisse und erben die Eigenschaften der übergeordneten Control-Group
Zeile 253: Zeile 176:
* Hierfür lassen sich die Cgroups ideal einsetzen
* Hierfür lassen sich die Cgroups ideal einsetzen


=== Virtualisiert ===
== Virtualisiert ==
 
Allerdings muss man beim Einsatz von Cgroups die Virtualisierung über die Libvirt-Bibliotheken steuern und LXC-Container oder Qemu/KVM verwenden
Allerdings muss man beim Einsatz von Cgroups die Virtualisierung über die Libvirt-Bibliotheken steuern und LXC-Container oder Qemu/KVM verwenden


Zeile 266: Zeile 188:
Das angestrebte Ziel lässt sich erreichen, indem man den Default-Wert von 1024 auf 2048 ändert
Das angestrebte Ziel lässt sich erreichen, indem man den Default-Wert von 1024 auf 2048 ändert


Genauso kann der Administrator auch den Verbrauch des Arbeitsspeichers oder die Bandbreitennutzung im Netzwerk konfigurieren
Genauso kann auch den Verbrauch des Arbeitsspeichers oder die Bandbreitennutzung im Netzwerk konfigurieren


Hierzu nutzt er den Memory-Controller oder den Net_Cls-Controller in Kombination mit dem ''<tt>tc</tt>'' -Befehl
Hierzu nutzt er den Memory-Controller oder den Net_Cls-Controller in Kombination mit dem ''<tt>tc</tt>'' -Befehl
* Allerdings unterstützen erst die aktuellsten Libvirt-Varianten den Net_Cls-Controller
* Allerdings unterstützen erst die aktuellsten Libvirt-Varianten den Net_Cls-Controller


Er unterscheidet sich von den anderen Controllern, da er lediglich eine Class-ID setzt und man dann mit dem Kommando ''<tt>tc</tt>'' die Bandbreite kontrolliert (siehe [http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux/%28offset%29/2#article_xbandbreitenkontrolle Kasten "Bandbreitenkontrolle"])
Er unterscheidet sich von den anderen Controllern, da er lediglich eine Class-ID setzt und man dann mit dem Kommando ''<tt>tc</tt>'' die Bandbreite kontrolliert (siehe [[#Bandbreitenkontrolle]])


Der Blkio-Controller lässt sich noch nicht mit Libvirt nutzen, da er noch nicht die Hierarchien unterstützt, die der Libvirtd erzeugen möchte
Der Blkio-Controller lässt sich noch nicht mit Libvirt nutzen, da er noch nicht die Hierarchien unterstützt, die der Libvirtd erzeugen möchte
* Daran arbeiten die Kernel-Entwickler aber schon [http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux/%28offset%29/4#article_i2 [2]]
* Daran arbeiten die Kernel-Entwickler aber schon


Will der Admin für die verbrauchte Zeit der einzelnen virtuellen Gäste Abrechnungen erstellen, so kann er das mit dem CPUAcct-Controller erreichen
Will der Admin für die verbrauchte Zeit der einzelnen virtuellen Gäste Abrechnungen erstellen, so kann er das mit dem CPUAcct-Controller erreichen
Zeile 280: Zeile 202:
Dieser zählt für jeden Gast in ''<tt>/cgroup/cpuacct/libvirt/qemu/''Gast''/cpuacct.usage</tt>'' die tatsächlich verbrauchte CPU-Zeit in Nano-Sekunden
Dieser zählt für jeden Gast in ''<tt>/cgroup/cpuacct/libvirt/qemu/''Gast''/cpuacct.usage</tt>'' die tatsächlich verbrauchte CPU-Zeit in Nano-Sekunden


=== Bandbreitenkontrolle ===
== Bandbreitenkontrolle ==
 
Wird ein Prozess vom Net_cls-Controller überwacht, kann der Admin für sämtliche Prozesse der Cgroup eine Class-ID vergeben
Wird ein Prozess vom Net_cls-Controller überwacht, kann der Admin für sämtliche Prozesse der Cgroup eine Class-ID vergeben
* Diese kann dann mit dem ''<tt>tc</tt>'' Kommando genutzt werden
* Diese kann dann mit dem ''<tt>tc</tt>'' Kommando genutzt werden
* Hierzu setzt der Admin zunächst für die Cgroup die Class-ID:


Hierzu setzt der Admin zunächst für die Cgroup die Class-ID:
<syntaxhighlight lang="bash" highlight="1" line copy>
echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/Gast/net_cls.classid
echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/Gast/net_cls.classid
</syntaxhighlight>


Diese hexadezimale Zahl besteht aus zwei Teilen: 0xAAAABBBB
Diese hexadezimale Zahl besteht aus zwei Teilen: 0xAAAABBBB
Zeile 300: Zeile 223:
Eine klassische QDisc für die Beschränkung des Netzwerkverkehrs ist der Hierarchical Token Bucket Filter (HTB)
Eine klassische QDisc für die Beschränkung des Netzwerkverkehrs ist der Hierarchical Token Bucket Filter (HTB)
* Der Admin muss zunächst diesen auf der Netzwerkkarte installieren
* Der Admin muss zunächst diesen auf der Netzwerkkarte installieren
* Hierzu löscht er eine möglicherweise vorhandene QDisc und lädt dann den HTB:


Hierzu löscht er eine möglicherweise vorhandene QDisc und lädt dann den HTB:
<syntaxhighlight lang="bash" highlight="1-2" line copy>
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev etho root handle 10: htbU
tc qdisc add dev etho root handle 10: htbU
</syntaxhighlight>


Nun muss der Admin die Klassen erzeugen
Nun muss der Admin die Klassen erzeugen
 
<syntaxhighlight lang="bash" highlight="1-2" line copy>
tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit
tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit
</syntaxhighlight>


Diese zwei Zeilen erzeugen zwei verschiedene Klassen
Diese zwei Zeilen erzeugen zwei verschiedene Klassen
Zeile 316: Zeile 242:


Um die Class-ID der Cgroup Net_Cls nun auszuwerten, muss der Admin noch einen Filter definieren:
Um die Class-ID der Cgroup Net_Cls nun auszuwerten, muss der Admin noch einen Filter definieren:
 
<syntaxhighlight lang="bash" highlight="1-3" line copy>
tc filter add dev eth0 parent 10: \
tc filter add dev eth0 parent 10: \
  protocol ip prio 10 \
  protocol ip prio 10 \
  handle 1: cgroup
  handle 1: cgroup
</syntaxhighlight>


Nun wird die Net_Cls-Class-ID automatisch von dem Kernel für die Einsortierung der Pakete in den HTB-Klassen genutzt
Nun wird die Net_Cls-Class-ID automatisch von dem Kernel für die Einsortierung der Pakete in den HTB-Klassen genutzt
Zeile 326: Zeile 253:
Jeder Thread eines Prozesses kann in einer eigenen Cgroup kontrolliert werden
Jeder Thread eines Prozesses kann in einer eigenen Cgroup kontrolliert werden


Daran muss der Administrator denken, wenn er, wie zu Beginn gezeigt, die Prozesse nach ihrem Start mit dem echo-Kommando einer Cgroup zuweisen möchte
Daran muss denken, wenn er, wie zu Beginn gezeigt, die Prozesse nach ihrem Start mit dem echo-Kommando einer Cgroup zuweisen möchte


Auch sämtliche gestarteten Threads (''<tt>/proc/pid/task/</tt>'' ) muss er entsprechenden Cgroups zuweisen
Auch sämtliche gestarteten Threads (''<tt>/proc/pid/task/</tt>'' ) muss er entsprechenden Cgroups zuweisen
Zeile 334: Zeile 261:
* Alle Kindprozesse und -threads erben dann diese Gruppe
* Alle Kindprozesse und -threads erben dann diese Gruppe


=== Fazit ===
== Aufruf ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>


Leider unterstützen nur die aktuellen Linux-Distributionen Cgroups
=== Optionen ===
{| class="wikitable sortable options gnu"
|-
! Unix !! GNU !! Parameter !! Beschreibung
|-
| || || ||
|-
|}


Einzelne Funktionen stehen sogar nur in den aktuellsten Linux-Kerneln zur Verfügung
=== Parameter ===


Der Administrator muss daher im Einzelfall testen, welche Eigenschaften er nutzen kann
=== Umgebungsvariablen ===


Dann bieten die Cgroups aber, insbesondere auch beim Einsatz von Virtualisierung, umfangreiche Funktionen für die Ressourcen-Steuerung der Prozesse und Gäste
=== Exit-Status ===
{| class="wikitable options col1center"
|-
! Wert !! Beschreibung
|-
| 0 || Erfolg
|-
| >0  || Fehler
|}


=== Quellen und Literatur ===
== Anwendung ==
 
=== cgroup tree ===
==== Quellen ====
<syntaxhighlight lang="bash" highlight="1" line copy>
 
sudo systemd-cgls
* Ralf Spenneberg ([http://www.admin-magazin.de/Das-Heft/2011/06 ADMIN 06/2011]<span style="background-color:#eeeeee;">)</span>http://www.admin-magazin.de/Das-Heft/2011/06/Cgroups-zur-Ressourcenkontrolle-in-Linux
 
 
 
==== Infos ====
 
# Cgroups: [http://www.kernel.org/doc/Documentation/cgroups/ http://www.kernel.org/doc/Documentation/cgroups/]
# Blkio-Hierarchien: [http://lwn.net/Articles/413015/ http://lwn.net/Articles/413015/]
 
 
{{DISPLAYTITLE:cgroups}}
 
== cgroup tree ==
# '''$ systemd-cgls'''
  └ system
  └ system
   ├ 1 /usr/lib/systemd/systemd --system --deserialize 18
   ├ 1 /usr/lib/systemd/systemd --system --deserialize 18
Zeile 431: Zeile 361:
   └ systemd-journald.service
   └ systemd-journald.service
     └ 280 /usr/lib/systemd/systemd-journald
     └ 280 /usr/lib/systemd/systemd-journald
</syntaxhighlight>


== ps with cgroups ==
=== ps with cgroups ===
'''$ alias psc='ps xawf -eo pid,user,cgroup,args''''
<syntaxhighlight lang="bash" highlight="1-2" line copy>
'''$ psc'''
alias psc='ps xawf -eo pid,user,cgroup,args
psc
   PID USER    CGROUP                              COMMAND
   PID USER    CGROUP                              COMMAND
  ...
  ...
Zeile 461: Zeile 393:
   994 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
   994 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
  ...
  ...
</syntaxhighlight>
=== Problembehebung ===


== Konfiguration ==
=== Dateien ===
{| class="wikitable options"
|-
! Datei !! Beschreibung
|-
| ||
|-
| ||
|}
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
=== Dokumentation ===
; Man-Page
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]
; Info-Pages
=== Links ===
==== Projekt ====
==== Weblinks ====


{{DEFAULTSORT:cgroups}}
{{DEFAULTSORT:cgroups}}
{{DISPLAYTITLE:cgroups}}
[[Kategorie:systemd]]
</noinclude>
{{DEFAULTSORT:cgroups}}
{{DISPLAYTITLE:cgroups}}

Aktuelle Version vom 11. Mai 2025, 13:46 Uhr

cgroup - Ressourcenkontrolle unter Linux

Beschreibung

Mit cgroups- lassen sich Ressourcen von Prozessen beschränken

Ressourcensteuerung und -kontrolle umsetzen

Genutzten Arbeitsspeicher eines einzelnen Prozesses oder einer Gruppe von Prozessen beschränken

Ursprünglich als "process container" bezeichnet, können die Control-Groups (kurz: cgroups) Ressourcen (Arbeitsspeicher, CPU, I/O) limitieren, priorisieren, zählen (für Abrechnungszwecke) und isolieren

Beim Einsatz etwa von KVM-Virtualisierung sehr interessant

  • Mit Cgroups lassen sich die Ressourcen eines virtuellen Gastes beschränken oder gegenüber anderen Gästen priorisieren

Gruppen

Mit einer cgroup können mehrere Prozesse zu einer Gruppe zusammenfasst werden

  • Diese Prozesse und sämtliche Kindprozesse kann dann mit Parametern für bestimmte Subsysteme versehen
  • Ein Subsystem ist dann etwa ein Ressource-Controller, der den verfügbaren Arbeitsspeicher verwaltet
Beispiel

Um die Cgroups zu verwenden, muss zunächst Hierarchien anlegen, in der die Gruppen verwaltet werden

Hierzu editiert er die Datei /etc/cgconfig.conf , die in zu sehen ist

  • Existiert die Datei nicht, so muss er das entsprechende Paket noch installieren

Diese Datei legt für jedes Subsystem eine eigene Hierarchie an, unterhalb derer die Cgroups angelegt werden können

  • Die Hierarchie /cgroup/cpu erlaubt die Verwaltung der CPU-Shares, während /cgroup/net_cls die Verwaltung der Netz-I/O-Leistung unterstützt
/etc/cgconfig.conf
01 mount {
02 cpuset = /cgroup/cpuset;
03 cpu = /cgroup/cpu;
04 cpuacct = /cgroup/cpuacct;
05 memory = /cgroup/memory;
06 devices = /cgroup/devices;
07 freezer = /cgroup/freezer;
08 net_cls = /cgroup/net_cls;
09 ns = /cgroup/ns;
10 blkio = /cgroup/blkio;
11 }
Cgroups-Dateisystem

Ein Start des Cgconfig-Daemons erzeugt dann die Verzeichnisse und mountet das Cgroups-Dateisystem

Mit dem Befehl lssubsys kontrolliert der Admin die korrekte Erzeugung der Hierarchien 

lssubsys
01 # lssubsys -am
02 cpuset /cgroup/cpuset
03 cpu /cgroup/cpu
04 cpuacct /cgroup/cpuacct
05 memory /cgroup/memory
06 devices /cgroup/devices
07 freezer /cgroup/freezer
08 net_cls /cgroup/net_cls
09 ns /cgroup/ns
10 blkio /cgroup/blkio
Control Group anlegen
cgcreate -g blkio:/dd
Block-I/O-Subsystem

Parameter für das Subsystem Block-I/O 

sudo cgget -g blkio /dd
/dd:
blkio.reset_stats=
blkio.io_queued=Total 0
blkio.io_merged=Total 0
blkio.io_wait_time=Total 0
blkio.io_service_time=Total 0
blkio.io_serviced=Total 0
blkio.io_service_bytes=Total 0

Seit der Version 2.6.37 unterstützt der Kernel hier auch die Optionen blkio.throttle.*

  • Damit kann die maximale I/O-Bandbreite beim Lesen und Schreiben einer Prozessgruppe einschränken

Um dies zu testen, benötigt der Admin zunächst die Major- und Minor-Nummern des Gerätes, auf dem die Bandbreite eingeschränkt werden soll

Handelt es sich um /dev/sda1 , kann er diese mit einem einfachen ls ermitteln: 

sudo ls -l /dev/sda1
brw-rw----. 1 root disk 8, 1 10. Okt 08:32 /dev/sda1

Hier handelt es sich um die Major/Minor-Nummern 8 respektive 1

  • Um die Bandbreite für die Control-Group nun auf 1 Mbyte/s zu beschränken, verwendet er den Befehl cgset oder einfach ein echo :
echo "8:1 1048576" > /cgroup/blkio/dd/blkio.throttle.write_bps_device

Für den Test startet er nun dd 

dd if=/dev/zero of=/tmp/test & pid=$!

Zunächst arbeitet der Prozess dd in der Root-Cgroup, die nicht eingeschränkt ist

Test

Prozess ein SIGUSR1 senden 

sudo kill -USR1 $pid
578804+0 Datensätze ein
578804+0 Datensätze aus
296347648 Bytes (296 MB) kopiert, 7,00803 s,42,3 MB/s
In die Cgroup verschieben

Prozess in die Cgroup ddverschieben 

sudo echo $pid > /cgroups/blkio/dd/tasks
Erneutes USR1-Signal
  • Sendet nun erneut ein USR1-Signal an den dd -Prozess
  • erkennt er, dass die durchschnittliche Bandbreite stark sinkt, da der Prozess nun nur noch mit einer Bandbreite von 1 MByte/s schreiben darf
  • Statt die maximale Bandbreite zu beschränken, kann der Admin auch die Bandbreiten zwischen den Gruppen priorisieren
blkio.weight

Hierzu dient der Parameter blkio.weight=

  • Der Default-Wert beträgt 500
  • Erhält eine Gruppe den Wert 1000, so kann sie doppelt so häufig auf die Block-Geräte zugreifen wie die anderen Gruppen
cgclassify

Statt des Echo-Kommandos lassen sich Prozesse auch mit dem Kommando cgclassify einzelnen Gruppen zuweisen

Prozess direkt in einer bestimmten Gruppe starten

Möchte der Admin einen Prozess direkt in einer bestimmten Gruppe starten, so verwendet er den Befehl cgexec : 

cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"

Automatik

Die manuelle Zuweisung von Prozessen zu verschiedenen Gruppen ist aufwendig und fehlerträchtig

  • Besser ist es deshalb, wenn der Daemon cgrulesengd diese Zuweisung auch automatisch übernimmt
  • Hierzu benötigt dieser Dienst die Regeldatei /etc/cgrules.conf , die ihm mitteilt, welcher Prozess von welchem Benutzer in welcher Control-Group landen soll
  • Die Datei besitzt eine recht einfache Syntax:
<user>[:<process] <controllers> <destination>

Für das Beispiel mit dem dd -Kommando sieht die Regel folgendermaßen aus: 

dd blkio /dd

Dies fügt die dd -Prozesse sämtlicher Benutzer der Controlgroup /dd des Blkio-Resource-Controllers hinzu


Hierarchien

Bisher betrachtet der Artikel nur einzelne isolierte Control-Groups

  • Zur besseren Strukturierung lassen sich aus Gruppen aber auch

Hierarchien bilden

  • So kann innerhalb einer Control-Group weitere Control-Groups anlegen, etwa mit cgreate -g blkio:/dd/user1

Diese erscheinen dann als Unterverzeichnisse und erben die Eigenschaften der übergeordneten Control-Group

Sämtliche Kind-Cgroups konkurrieren dann um die der übergeordneten Cgroup zugeteilten Ressourcen

  • Darf diese nur 1 MByte/s schreiben, dürfen sämtliche Kind-Cgroups zusammen dieses Maximum nicht überschreiten

Die Ressourcen werden hierarchisch zugewiesen

  • Leider funktionieren diese Hierarchien für den Blkio-Controller noch nicht
  • Die anderen Controller wie CPU, Memory und so weiter unterstützen aber bereits Hierarchien

Wo können die Cgroups nun sinnvoll eingesetzt werden? Sicher gibt es spezielle Anwendungen, die im Alltag davon profitieren können

Jedoch ist es in vielen Fällen sinnvoller, dass der Linux-Kernel die Ressourcen selbstständig zuweist und hierbei keine Schranken setzt

Setzt man jedoch eine Virtualisierungslösung wie KVM ein und virtualisiert mehrere Gäste auf einem Host, gibt es durchaus Bedarf, die Ressourcennutzung der einzelnen Gäste untereinander zu beschränken, priorisieren und zu messen

  • Hierfür lassen sich die Cgroups ideal einsetzen

Virtualisiert

Allerdings muss man beim Einsatz von Cgroups die Virtualisierung über die Libvirt-Bibliotheken steuern und LXC-Container oder Qemu/KVM verwenden

Der Libvirtd-Daemon erzeugt dann beim Start für jeden Gast eine eigene Cgroup mit dem Namen des Gastes

Diese befindet sich in der Hierarchie libvirtd/qemu|lxc/Gast unter jedem Controller

  • Hier kann der Admin nun für jeden Gast einzeln die Ressourcen verwalten und priorisieren

Damit ein Gast doppelt so viel CPU-Zeit wie ein zweiter Gast erhalten kann, muss man im CPU-Controller die cpu.shares ändern

Das angestrebte Ziel lässt sich erreichen, indem man den Default-Wert von 1024 auf 2048 ändert

Genauso kann auch den Verbrauch des Arbeitsspeichers oder die Bandbreitennutzung im Netzwerk konfigurieren

Hierzu nutzt er den Memory-Controller oder den Net_Cls-Controller in Kombination mit dem tc -Befehl

  • Allerdings unterstützen erst die aktuellsten Libvirt-Varianten den Net_Cls-Controller

Er unterscheidet sich von den anderen Controllern, da er lediglich eine Class-ID setzt und man dann mit dem Kommando tc die Bandbreite kontrolliert (siehe #Bandbreitenkontrolle)

Der Blkio-Controller lässt sich noch nicht mit Libvirt nutzen, da er noch nicht die Hierarchien unterstützt, die der Libvirtd erzeugen möchte

  • Daran arbeiten die Kernel-Entwickler aber schon

Will der Admin für die verbrauchte Zeit der einzelnen virtuellen Gäste Abrechnungen erstellen, so kann er das mit dem CPUAcct-Controller erreichen

Dieser zählt für jeden Gast in /cgroup/cpuacct/libvirt/qemu/Gast/cpuacct.usage die tatsächlich verbrauchte CPU-Zeit in Nano-Sekunden

Bandbreitenkontrolle

Wird ein Prozess vom Net_cls-Controller überwacht, kann der Admin für sämtliche Prozesse der Cgroup eine Class-ID vergeben

  • Diese kann dann mit dem tc Kommando genutzt werden

Hierzu setzt der Admin zunächst für die Cgroup die Class-ID: 

echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/Gast/net_cls.classid

Diese hexadezimale Zahl besteht aus zwei Teilen: 0xAAAABBBB

  • Hierbei definieren die Ziffern AAAA die Major-Nummer der Class-ID, während die Ziffern BBBB die Minor-Nummer angeben
  • Führende Nullen müssen nicht angegeben werden
  • Der obige Ausdruck hätte also auch 0x100001 lauten können

Um nun die Class-ID zu nutzen, muss der Admin eine Classbased-Queueing-Discipline (QDisc) auf der ausgehenden Netzwerkkarte (etwas eth0 ) installieren

Die QDisc entscheidet, wann ein Paket zu versenden ist

  • Eine klassenbasierte QDisc erlaubt die Einsortierung der Pakete in unterschiedliche Klassen sowie die Priorisierung und Beschränkung dieser Klassen

Eine klassische QDisc für die Beschränkung des Netzwerkverkehrs ist der Hierarchical Token Bucket Filter (HTB)

  • Der Admin muss zunächst diesen auf der Netzwerkkarte installieren

Hierzu löscht er eine möglicherweise vorhandene QDisc und lädt dann den HTB: 

tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev etho root handle 10: htbU

Nun muss der Admin die Klassen erzeugen 

tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit

Diese zwei Zeilen erzeugen zwei verschiedene Klassen

  • Die erste Klasse verfügt über eine maximale Bandbreite von 10 Megabit/s
  • Die zwei Klasse verfügt über 20 Megabit/s, darf jedoch bis zu einer maximalen Bandbreite von 100 Mbit/s beanspruchen, wenn keine andere Klasse Ansprüche erhebt
  • Die Option default 2 bei der Erzeugung des HTB weist unklassifizierten Verkehr der zweiten Klasse zu

Um die Class-ID der Cgroup Net_Cls nun auszuwerten, muss der Admin noch einen Filter definieren: 

tc filter add dev eth0 parent 10: \
 protocol ip prio 10 \
 handle 1: cgroup

Nun wird die Net_Cls-Class-ID automatisch von dem Kernel für die Einsortierung der Pakete in den HTB-Klassen genutzt

  • Der Libvirt-Gast erhält nun eine maximale Sendeleistung von 10 Mbit/s

Jeder Thread eines Prozesses kann in einer eigenen Cgroup kontrolliert werden

Daran muss denken, wenn er, wie zu Beginn gezeigt, die Prozesse nach ihrem Start mit dem echo-Kommando einer Cgroup zuweisen möchte

Auch sämtliche gestarteten Threads (/proc/pid/task/ ) muss er entsprechenden Cgroups zuweisen

Einfacher ist da das Kommando cgexec

  • Dieser Befehl startet den Prozess bereits in der Cgroup
  • Alle Kindprozesse und -threads erben dann diese Gruppe

Aufruf

Optionen

Unix GNU Parameter Beschreibung

Parameter

Umgebungsvariablen

Exit-Status

Wert Beschreibung
0 Erfolg
>0 Fehler

Anwendung

cgroup tree

sudo systemd-cgls
 └ system
   ├ 1 /usr/lib/systemd/systemd --system --deserialize 18
   ├ ntpd.service
   │ └ 8471 /usr/sbin/ntpd -u ntp:ntp -g
   ├ upower.service
   │ └ 798 /usr/libexec/upowerd
   ├ wpa_supplicant.service
   │ └ 751 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
   ├ nfs-idmap.service
   │ └ 731 /usr/sbin/rpc.idmapd
   ├ nfs-rquotad.service
   │ └ 753 /usr/sbin/rpc.rquotad
   ├ nfs-mountd.service
   │ └ 732 /usr/sbin/rpc.mountd
   ├ nfs-lock.service
   │ └ 704 /sbin/rpc.statd
   ├ rpcbind.service
   │ └ 680 /sbin/rpcbind -w
   ├ postfix.service
   │ ├   859 /usr/libexec/postfix/master
   │ ├   877 qmgr -l -t fifo -u
   │ └ 32271 pickup -l -t fifo -u
   ├ colord-sane.service
   │ └ 647 /usr/libexec/colord-sane
   ├ udisks2.service
   │ └ 615 /usr/lib/udisks2/udisksd --no-debug
   ├ colord.service
   │ └ 607 /usr/libexec/colord
   ├ prefdm.service
   │ ├ 567 /usr/sbin/gdm-binary -nodaemon
   │ ├ 602 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
   │ ├ 612 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-O00GPA/database -seat seat0 -nolisten tcp
   │ └ 905 gdm-session-worker [pam/gdm-password]
   ├ systemd-ask-password-wall.service
   │ └ 645 /usr/bin/systemd-tty-ask-password-agent --wall
   ├ atd.service
   │ └ 544 /usr/sbin/atd -f
   ├ ksmtuned.service
   │ ├  548 /bin/bash /usr/sbin/ksmtuned
   │ └ 1092 sleep 60
   ├ dbus.service
   │ ├ 586 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
   │ ├ 601 /usr/libexec/polkit-1/polkitd --no-debug
   │ └ 657 /usr/sbin/modem-manager
   ├ cups.service
   │ └ 508 /usr/sbin/cupsd -f
   ├ avahi-daemon.service
   │ ├ 506 avahi-daemon: running [epsilon.local]
   │ └ 516 avahi-daemon: chroot helper
   ├ system-setup-keyboard.service
   │ └ 504 /usr/bin/system-setup-keyboard
   ├ accounts-daemon.service
   │ └ 502 /usr/libexec/accounts-daemon
   ├ systemd-logind.service
   │ └ 498 /usr/lib/systemd/systemd-logind
   ├ crond.service
   │ └ 486 /usr/sbin/crond -n
   ├ NetworkManager.service
   │ ├  484 /usr/sbin/NetworkManager --no-daemon
   │ └ 8437 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-903b6f6aa7a1-46c8-82a9-7f637dfbb3e4-wlan0.lease -cf /var/run/nm-d...
   ├ libvirtd.service
   │ ├ 480 /usr/sbin/libvirtd
   │ └ 571 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listenaddress 192.168.122.1 --dhcp-range 192.168.122.2,1...
   ├ bluetooth.service
   │ └ 479 /usr/sbin/bluetoothd -n
   ├ systemd-udev.service
   │ └ 287 /usr/lib/systemd/systemd-udevd
   └ systemd-journald.service
     └ 280 /usr/lib/systemd/systemd-journald

ps with cgroups

alias psc='ps xawf -eo pid,user,cgroup,args
psc
   PID USER     CGROUP                              COMMAND
 ...
     1 root     name=systemd:/systemd-1             /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0
   415 root     name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
   928 root     name=systemd:/systemd-1/atd.service /usr/sbin/atd -f
   930 root     name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n
   932 root     name=systemd:/systemd-1/crond.service /usr/sbin/crond -n
   935 root     name=systemd:/systemd-1/auditd.service /sbin/auditd -n
   943 root     name=systemd:/systemd-1/auditd.service  \_ /sbin/audispd
   964 root     name=systemd:/systemd-1/auditd.service      \_ /usr/sbin/sedispatch
   937 root     name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f
   941 rpc      name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f
   944 root     name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4
   947 root     name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
   950 root     name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f
   955 dbus     name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
   969 root     name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6
   970 root     name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5
   971 root     name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1
   973 root     name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4
   974 root     name=systemd:/user/lennart/2        login -- lennart
  1824 lennart  name=systemd:/user/lennart/2         \_ -bash
   975 root     name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3
   988 root     name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd
   994 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
 ...

Problembehebung

Konfiguration

Dateien

Datei Beschreibung


Anhang

Siehe auch


Dokumentation

Man-Page
  1. prep(1)
Info-Pages

Links

Projekt

Weblinks




Abgerufen von „https://wiki.foxtom.de/index.php?title=Cgroups&oldid=141619“