Provided by: manpages-sv_4.21.0-2_all 
NAMN
cgroups — Linux styrgrupper
BESKRIVNING
Styrgrupper, vanligen refererade till som cgroups, är en funktion i Linuxkärnan som gör att processer kan
organiseras i hierarkiska grupper vars användning av olika typer av resurser sedan kan begränsas och
övervakas. Kärnans cgroup-gränssnitt tillhandahålls via ett pseudofilsystem som kallas cgroupfs.
Gruppering implementeras i kärnans centrala cgroup-kod, medan resursspårning och -begränsning
implementeras i ett antal undersystem per resurstyp (minne, CPU, och så vidare).
Terminologi
En cgroup är en samling av processer som är bundna av en uppsättning gränser eller parametrar som
definieras via cgroup-filsystemet.
Ett undersystem är en kärnkomponent som modifierar beteendet hos processerna i en cgroup. Olika
undersystem har implementerats, vilket gör det möjligt att göra saker som att begränsa mängden CPU-tid
och minne som är tillgängligt i en cgroup, bokföring av CPU-tiden som används av en cgroup och frysning
och återupptagande av körningen av processerna i en cgroup. Undersystem är också ibland kända som
resurshanterare (resource controllers) (eller helt enkelt, hanterare (controllers)).
En hanterares cgroups är arrangerade i en hierarki. Denna hierarki defineras genom att skapa, ta bort och
byta namn på underkataloger i cgroup-filsystemet. På varje nivå av hierarkin kan attribut (t.ex.,
gränser) definieras. Gränserna, styrningen och bokföringen som erbjuds av cgroups har allmänt sett
påverkan genom underhierarkin under den cgroup där attributen definieras. Alltså kan till exempel inte
gränserna som placeras på en cgroup på en högre nivå i hierarkin överskridas av avkomme-cgroups.
Cgroups version 1 och version 2
Den ursprungliga utgåvan av cgroups-implementationen var i Linux 2.6.24. Med tiden har olika
cgroup-hanterare lagts till för att möjliggöra hanteringen av olika typer av resurser. Dock var
utvecklingen av dessa hanterare i stort sett okoordinerad, med resultatet att många inkonsistenser
uppstod mellan hanterare och användandet av cgroup-hierarkier blev ganska komplext. En längre beskrivning
av dessa problem finns i kärnans källfil Documentation/admin-guide/cgroup-v2.rst (eller
Documentation/cgroup-v2.txt i Linux 4.17 och tidigare).
På grund av problemen med den ursprungliga cgroups-implementationen (cgroups version 1) inleddes, med
början i Linux 3.10, arbete på en ny, ortogonal implementation för att åtgärda dessa problem. Från början
markerad experimentell, och dold bakom monteringsflaggan -o __DEVEL__sane_behavior gjordes den nya
versionen (cgroups version 2) slutligen officiell i och med utgåvan av Linux 4.5. Skillnader mellan de
två versionerna beskrivs i texten nedan. Filen cgroup.sane_behavior, som finns i cgroups v1, är en relik
från denna monteringsflagga. Filen rapporterar alltid ”0” och finns bara kvar för bakåtkompatibilitet.
Även om cgroups v2 är avsett att vara en ersättning för cgroups v1 finns det äldre systemet kvar (och av
kompatibilitetsskäl är det osannolikt att det kommer tas bort). För närvarande implementerar cgroups v2
endast en delmängd av hanterarna som är tillgängliga i cgroups v1. De två systemen är implementerade så
att både v1-hanterare och v2-hanterare kan monteras på samma system. Alltså är det till exempel möjligt
att använda de hanterare som stödjs under version 2, men också använda version 1-hanterare där version 2
ännu inte stödjer dessa hanterare. Den enda begränsningen är att en hanterare inte samtidigt kan användas
i både en cgroups v1-hierarki och i cgroups v2-hierarkin.
CGROUPS VERSION 1
Under cgroups v1 kan varje hanterare monteras mot ett separat cgroup-filsystem som ger sin egen
hierarkiska organisation av processerna på systemet. Det är också möjligt att sammontera flera (eller
alla) cgroups v1-hanterare mot samma cgroup-filsystem, vilket betyder att de sammonterade hanterarna
använder samma hierarkiska organisation av processer.
För varje monterad hierarki avspeglar katalogträdet styrgruppshierarkin. Varje styrgrupp representeras av
en katalog, där var och en av dess barnstyr-cgroup representeras av en barnkatalog. Till exempel
representerar /user/johan/1.session styrgruppen 1.session, vilken är ett barn till johan, vilken är ett
barn till /user. Under varje cgroup-katalog finns en uppsättning filer vilka kan läsas eller skrivas
till, vilket avspeglar resursbegränsningar och några allmänna cgroup-egenskaper.
Uppgifter (trådar) respektive processer
I cgroups v1 dras en distinktion mellan processer och uppgifter. I denna vy kan en process bestå av flera
uppgifter (oftare kallade trådar, från ett användarperspektiv, och kallas så i resten av denna
manualsida). I cgroups v1 är det möjligt att hantera cgroup-medlemskapet hos trådarna i en process
oberoende av varandra.
Cgroups v1 möjlighet att dela trådar över olika cgroups orsakade problem i en del fall. Till exempel var
det inte meningsfullt för minneshanteraren eftersom alla trådarna i en process delar en enda adressrymd.
På grund av dessa problem togs möjlighetn att oberoende hantera cgroup-medlemskapet hos trådar i en
process bort i den ursprungliga cgroups v2-implementationen, och återställdes senare i en mer begränsad
form (se diskussionen om ”trådläge” nedan).
Montering av v1-hanterare
Användningen av cgroups förutsätter en kärna byggd med alternativet CONFIG_CGROUP. Dessutom har var och
en av v1-hanterarna ett associerat konfigurationsalternativ som måste vara satt för att använda den
hanteraren.
För att använda en v1-hanterare måste den monteras mot ett cgroup-filsystem. Den vanliga platsen för
sådana monteringar är under ett tmpfs(5)-filsystem monterat på /sys/fs/cgroup. Man kan alltså montera
cpu-hanteraren enligt följande:
mount -t cgroup -o cpu none /sys/fs/cgroup/cpu
Det är möjligt att sammontera flera hanterare mot samma hierarki. Till exempel sammonteras här hanterarna
cpu och cpuacct mot en enda hierarki:
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
Sammontering av hanterare har effekten att en process är i samma cgroup för alla sammonterade hanterare.
Separat monterade hanterare gör det möjligt för en process att finnas i en cgroup /apa1 för en hanterare
medan den finns i /apa2/apa3 för en annan.
Det är möjligt att sammontera alla v1-hanterare mot samma hierarki:
mount -t cgroup -o all cgroup /sys/fs/cgroup
(Man kan åstadkomma samma resultat genom att utelämna -o all eftersom det är standardbeteendet om inga
hanterare uttryckligen anges.)
Det är inte möjligt att montera samma hanterare mot flera cgroup-hierarkier. Till exempel är det inte
möjligt att montera både hanteraren cpu och cpuacct mot en hierarki, och att montera hanteraren cpu ensam
mot en annan hierarki. Det är möjligt att skapa flera monteringar med exakt samma uppsättning av
sammonterade hanterare. I det fallet är dock det enda som händer att flera monteringspunkter ger en vy av
samma hierarki.
Observera att på många system är v1-hanterarna automatiskt monterade under /sys/fs/cgroup; speciellt
skapar systemd(1) automatiskt sådana monteringar.
Avmontering av v1-hanterare
Ett monterat cgroup-filsystem kan avmonteras med kommandot umount(8), som i följande exempel:
umount /sys/fs/cgroup/pids
Men observera även: ett cgroup-filsystem avmonteras bara om det inte är upptaget, det vill säga att det
inte har någon barn-cgroup. Om det inte är fallet är enda effekten av umount(8) att göra monteringen
osynlig. Alltså måste man för att säkerställa att en montering verkligen tas bort först ta bort alla
barn-cgroup:er, vilket i sin tur endast kan göras efter att alla medlemsprocesser har flyttats ifrån
dessa cgroup:er till root-cgroup:en.
Cgroup version 1-hanterare
Varje hanterare i cgroup version 1 styrs av ett kärnkonfigurationsalternativ (uppräknat nedan). Dessutom
styrs tillgängligheten av funktionen cgroup av kärnkonfigurationsalternativet CONFIG_CGROUPS.
cpu (från Linux 2.6.24; CONFIG_CGROUP_SCHED)
Cgroups kan garanteras ett minsta antal ”CPU-andelar” när ett system är belastat. Detta begränsar
inte en cgroup:s CPU-användning om CPU:erna inte är belastade. För ytterligare information, se
Documentation/scheduler/sched-design-CFS.rst (eller Documentation/scheduler/sched-design-CFS.txt i
Linux 5.2 och tidigare).
I Linux 3.2 utökades denna styrgrupp till att tillandahålla styrning av ”CPU-bandbredd”. Om kärnan
konfigureras med CONFIG_CFS_BANDWIDTH är det, inom varje schemaläggningsperiod (definierad via en
fil i cgroup-katalogen), möjligt att definiera en övre gräns på CPU-tiden som tilldelas till
processer i en cgroup. Denna övre gräns gäller även om det inte finns någon annan konkurrens om
CPU:n. Ytterligare information finns i kärnans källfil Documentation/scheduler/sched-bwc.rst
(eller Documentation/scheduler/sched-bwc.txt i Linux 5.2 och tidigare).
cpuacct (sedan Linux 2.6.24; CONFIG_CGROUP_CPUACCT)
Denna tillhandahåller bokföring av CPU-användning av grupper av processer.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/cpuacct.rst
(eller Documentation/cgroup-v1/cpuacct.txt i Linux 5.2 och tidigare).
cpuset (sedan Linux 2.6.24; CONFIG_CPUSETS)
Denna cgroup kan användas för att binda processerna i en cgroup till en specifik uppsättning av
CPU:er och NUMA-noder.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/cpusets.rst
(eller Documentation/cgroup-v1/cpusets.txt i Linux 5.2 och tidigare).
memory (sedan Linux 2.6.25; CONFIG_MEMCG)
Minneshanteraren stödjer rapportering och begränsning av processminne, kärnminne och växling som
används av cgroup:er.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/memory.rst
(eller Documentation/cgroup-v1/memory.txt i Linux 5.2 och tidigare).
devices (sedan Linux 2.6.26; CONFIG_CGROUP_DEVICE)
Detta stödjer styrning av vilka processer som får skapa (mknod) enheter liksom öppna dem för
läsning eller skrivning. Policyerna kan anges som tillåtelselistor och nekandelistor. Hierarkin
upprätthålls, så att nya regler inte får bryta mot befintliga regler för målet eller
anfader-cgroup:er.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/devices.rst
(eller Documentation/cgroup-v1/devices.txt i Linux 5.2 och tidigare).
freezer (sedan Linux 2.6.28; CONFIG_CGROUP_FREEZER)
Cgroup:en freezer kan försätta alla processer i en cgroup i vänteläge (suspend) och återuppta
(resume) dem. Att frysa en cgroup /A får även dess barn, till exempel processer i /A/B, att
frysas.
Ytterligare information finns i kärnans källfil
Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst (eller
Documentation/cgroup-v1/freezer-subsystem.txt i Linux 5.2 och tidigare).
net_cls (sedan Linux 2.6.29; CONFIG_CGROUP_NET_CLASSID)
Denna lägger ett klass-id, angivet för cgroup:en, på nätverkspaket som skapas av en cgroup. Dessa
klass-id:n kan sedan användas i brandväggsregler, liksom användas för att forma trafiken med
tc(8). Detta gäller endast paket som lämnar cgroup:en, inte trafik som kommer till cgroup:en.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/net_cls.rst
(eller Documentation/cgroup-v1/net_cls.txt i Linux 5.2 och tidigare).
blkio (sedan Linux 2.6.33; CONFIG_BLK_CGROUP)
Cgroup:en blkio styr och begränsar åtkomst till angivna blockenheter genom att lägga på
IO-styrning i form av strypning och övre gränser på lövnoder och mellanliggande noder i
lagringshierarkin.
Två policyer är tillgängliga. Den första är med proportionell vikt tidsbaserad uppdelning av disk
implementerad med CFQ. Denna är i kraft för lövnoder som använder CFQ. Den andra är en
strypningspolicy som anger övre gränser för I/O-hastighet för en enhet.
Ytterligare information finns i kärnans källfil
Documentation/admin-guide/cgroup-v1/blkio-controller.rst (eller
Documentation/cgroup-v1/blkio-controller.txt i Linux 5.2 och tidigare).
perf_event (sedan Linux 2.6.39; CONFIG_CGROUP_PERF)
Denna hanterare medger perf-övervakning av uppsättningen processer som är grupperade i en cgroup.
Ytterligare information finns i kärnans källfiler
net_prio (sedan Linux 3.3; CONFIG_CGROUP_NET_PRIO)
Denna tillåter att prioriteter anges, per nätverksgränssnitt, för cgroup:er.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/net_prio.rst
(eller Documentation/cgroup-v1/net_prio.txt i Linux 5.2 och tidigare).
hugetlb (sedan Linux 3.5; CONFIG_CGROUP_HUGETLB)
Denna stödjer att man begränsar användningen av väldiga sidor med styrgrupper.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/hugetlb.rst
(eller Documentation/cgroup-v1/hugetlb.txt i Linux 5.2 och tidigare).
pids (sedan Linux 4.3; CONFIG_CGROUP_PIDS)
Denna hanterare tillåter att man begränsar antalet processer som kan skapas i en styrgrupp (och
dess avkommor).
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/pids.rst
(eller Documentation/cgroup-v1/pids.txt i Linux 5.2 och senare).
rdma (sedan Linux 4.11; CONFIG_CGROUP_RDMA)
RDMA-hanteraren tillåter att man begränsar användningen av RDMA/IB-specifika resurser per
styrgrupp.
Ytterligare information finns i kärnans källfil Documentation/admin-guide/cgroup-v1/rdma.rst
(eller Documentation/cgroup-v1/rdma.txt i Linux 5.2 och tidigare).
Att skapa styrgrupper och flytta processer
Ett styrgruppfilsystem innehåller initialt en ensam rotstyrgrupp, ”/”, vilken alla processer hör till. En
ny styrgrupp skapas genom att skapa en katalog i styrgruppfilsystemet:
mkdir /sys/fs/cgroup/cpu/sg1
Detta skapar en ny tom styrgrupp.
En process kan flyttas till denna styrgrup genom att skriva dess PID in i styrgruppens fil cgroup.procs:
echo $$ > /sys/fs/cgroup/cpu/sg1/cgroup.procs
Endast en PID åt gången får skrivas till denna fil.
Om man skriver värdet 0 till en fil cgroup.procs flyttas den skrivande processen till motsvarande
styrgrupp.
När man skriver ett PID in i cgroup.procs flyttas alla trådar i processen in i den nya styrgruppen på en
gång.
Inom en hierarki kan en process vara medlem av precis en styrgrupp. När man skriver en process PID till
en fil cgroup.procs tas den automatiskt bort från den styrgrupp den var medlem av tidigare.
Filen cgroup.procs kan läsas för att hämta en lista på processer som är medlemmar av en styrgrupp. Den
returnerade listan av PID:er är inte garanterat i ordning. Inte heller är den garanterat fri från
upprepningar. (Till exempel kan ett PID ha blivit återanvänt medan listan lästes.)
I cgroups v1 kan en enskild tråd flyttas till en annan styrgrupp genom att skriva dess tråd-ID (d.v.s.,
kärnans tråd-ID returnerat från clone(2) och gettid(2)) till filen tasks i en styrgruppskatalog. Denna
fil kan läsas för att se uppsättningen av trådar som är medlemmar av styrgruppen.
Att ta bort styrgrupper
För att ta bort en styrgrupp får den först inte ha några barnstyrgrupper och inte innehålla några
processer (andra än zombier). Förutsatt att det är fallet kan man helt enkelt ta bort motsvarande
katalogsökväg. Observera att filer i en styrgruppskatalog inte kan och inte behöver tas bort.
Cgroups v1 notifieringar om släpp
Två filer kan användas för att avgöra huruvida kärnan skall tillhandahålla notifieringar när en styrgrupp
blir tom. En styrgrupp anses tom när den inte innehåller några barnstyrgrupper och inga medlemsprocesser.
En speciell fil i rotkatalogen av varje styrgruppshierarki, release_agent, kan användas för att
registrera sökvägsnamnet till ett program som kan anropas när en styrgrupp i hierarkin blir tom. Sökvägen
till den nyss tömda styrgruppen (relativt monteringspunkten för styrgrupper) ges som det enda
kommandoradsargumentet när programmet release_agent anropas. Programmet release_agent kan ta bort
styrgruppskatalogen, eller kanske återpopulera den med en process.
Standardvärdet i filen release_agent är tomt, vilket betyder att ingen släppagent anropas.
Innehållet i filen release_agent kan också anges via en monteringsflagga när styrgruppsfilsystemet
monteras:
mount -o release_agent=sökväg …
Huruvida programmet release_agent anropas eller inte när en viss styrgrupp blir tom avgörs av värdet i
filen notify_on_release i motsvarande styrgruppskatalog. Om denna fil innehåller värdet 0, då anropas
inte programmet release_agent. Om den innehåller värdet 1 anropas programmet release_agent.
Standardvärdet i denna fil i rotstyrgruppen är 0. När en ny styrgrupp skapas ärvs värdet i denna fil från
motsvarande fil i föräldrastyrgruppen.
Cgroup v1 namngivna hierarkier
I cgroups v1 är det möjligt att montera en styrgruppshierarki som inte har några tillkopplade hanterare:
mount -t cgroup -o none,name=ngtnamn none /någon/monterings/punkt
Flera instanser av sådana hierarkier kan monteras; varje hierarki måste ha ett unikt namn. Det enda
syftet med sådana hierarkier är att spåra processer. (Se diskussionen om släppnotifieringar nedan.) Ett
exempel på detta är styrgruppshierarkin name=systemd som används av systemd(1) för att spåra tjänster och
användarsessioner.
Sedan Linux 5.0 kan kärnans uppstartsflagga cgroup_no_v1 (beskriven nedan) användas till att avaktivera
namngivna hierarkier inom cgroup v1, genom att ange cgroup_no_v1=namngiven.
CGROUPS VERSION 2
I cgroups v2 bor alla monterade hanterare i en enda sammanslagen hierarki. Även om (olika) hanterare kan
monteras samtidigt under v1- och v2-hierarkierna är det inte möjligt att montera samma hanterare
samtidigt under både v1- och v2-hierarkierna.
De nya beteendena i cgroups v2 sammanfattas här, och utvecklas i några fall i de följande underavsnitten.
• Cgroups v2 tillhandahåller en sammanslagen hierarki mot vilken alla hanterare monteras.
• ”Interna” processer är inte tillåtna. Med undantag av rotstyrgruppen kan processer endast finnas i
lövnoder (styrgrupper som inte själva innehåller barnstyrgrupper). Detaljerna är något mer subtila än
detta, och beskrivs nedan.
• Aktiva styrgrupper måste anges via filerna cgroup.controllers och cgroup.subtree_control.
• Filen tasks har tagits bort. Dessutom har filen cgroup.clone_children som används i hanteraren cpuset
tagits bort.
• En förbättrad mekanism för notifieringar om tomma styrgrupper ges av filen cgroup.events.
För fler ändringar, se filen Documentation/admin-guide/cgroup-v2.rst i kärnans källa (eller
Documentation/cgroup-v2.txt i Linux 4.17 och tidigare).
Några av de nya beteendena ovan modifierades senare med tillägget i Linux 4.14 av ”trådläge” (beskrivet
nedan).
Cgroups v2 sammanslagen hierarki
I cgroups v1 var möjligheten att montera olika hanterare mot olika hierarkier avsedd att ge en stor
flexibilitet i designen av program. I praktiken visade sig dock flexibiliteten vara mindre användbar än
förväntat, och i många fall lade den till komplexitet. Därför monteras i cgroups v2 alla tillgängliga
hanterare mot en enda hierarki. De tillgängliga hanterarna monteras automatiskt, vilket betyder att det
inte är nödvändigt (eller möjligt) att ange hanterarna när man monterar filsystemet för cgroups v2 med
ett kommando som det följande:
mount -t cgroup2 none /mnt/cgroup2
En hanterare i cgroup v2 är tillgänglig endast om den inte för närvarande används via en montering mot en
cgroup v1-hierarki. Eller, för att uttrycka det på ett annat sätt, är det inte möjligt att använda samma
hanterare mot både en v1-hierarki och den sammanslagna v2-hierarkin. Detta betyder att det kan vara
nödvändigt att först avmontera en v1-hanterare (som beskrivet ovan) före den hanteraren är tillgänglig i
v2. Eftersom systemd(1) normalt använder sig mycket av några v1-hanterare kan det i några fall vara
enklare att starta med de valda v1-hanterarna avaktiverade. För att göra detta, ange flaggan
cgroup_no_v1=lista på kärnans startkommandorad; lista är en kommaseparerad lista av namnen på hanterare
att avaktivera, eller ordet all för att avaktivera alla v1-hanterare. (Denna situation hanteras korrekt
av systemd(1) som faller tillbaka på att arbeta utan de angivna hanterarna.)
Observera att på många moderna system monterar systemd(1) automatiskt filsystemet cgroup2 på
/sys/fs/cgroup/unified under uppstartsprocessen.
Cgroups v2 monteringsflaggor
Följande flaggor (mount -o) kan anges vid montering av cgroup v2-filsystemet:
nsdelegate (sedan Linux 4.15)
Behandla styrgruppsnamnrymder som delegeringsgränser. För detaljer se nedan.
memory_localevents (sedan Linux 5.2)
memory.events skall visa statistik endast för styrgruppen själv, och inte för några
avkommestyrgrupper. Detta var beteendet före Linux 5.2. Med början i Linux 5.2 är
standardbeteendet att inkludera statistik för avkommestyrgrupper i memory.events, och denna
monteringsflagga kan användas för att återgå till det tidigare beteendet. Denna flagga är
systemvid och kan anges vid monteringar eller ändras genom ommonteringar endast från den intiala
monteringsnamnrymden; den ignoreras tyst i andra namnrymder än den initiala.
Cgroups v2-hanterare
Följande hanterare, dokumenterade i kärnans källfil Documentation/admin-guide/cgroup-v2.rst (eller
Documentation/cgroup-v2.txt i Linux 4.17 och tidigare), stödjs i styrgrupper version 2:
cpu (sedan Linux 4.15)
Detta är efterföljaren till hanterarna cpu och cpuacct i version 1.
cpuset (sedan Linux 5.0)
Detta är efterföljaren till hanteraren cpuset i version 1.
freezer (sedan Linux 5.2)
Detta är efterföljaren till hanteraren freezer i version 1.
hugetlb (sedan Linux 5.6)
Detta är efterföljaren till hanteraren hugetlb i version 1.
io (sedan Linux 4.5)
Detta är efterföljaren till hanteraren blkio i version 1.
memory (sedan Linux 4.5)
Detta är efterföljaren till hanteraren memory i version 1.
perf_event (sedan Linux 4.11)
Detta är samma som hanteraren perf_event i version 1.
pids (sedan Linux 4.5)
Detta är samma som hanteraren pids i version 1.
rdma (sedan Linux 4.11)
Detta är samma som hanteraren rdma i version 1.
Det finns ingen direkt motsvarighet till hanterarna net_cls och net_prio från styrgrupper version 1.
Istället har stöd lagts till i iptables(8) för att tillåta eBPF-filter att haka på sökvägar i cgroup v2
för att ta beslut om nätverkstrafik baserat på styrgrupp.
Hanteraren devices i v2 ger inget gränssnitt till filer; istället begränsas enhetsstyrningen genom att
koppla ett eBPF-program (BPF_CGROUP_DEVICE) till en v2-styrgrupp.
Cgroups v2 underträdsstyrning
Varje styrgrupp i v2-hierarkin innehåller följande två filer:
cgroup.controllers
Denna endast läsbara fil exponerar en lista av hanterarna som finns tillgängliga i denna
styrgrupp. Innehållet i denna fil motsvarar innehållet i filen cgroup.subtree_control i
föräldrastyrgruppen.
cgroup.subtree_control
Detta är en lista över hanterare som är aktiva (aktiverade) i styrgruppen. Uppsättningen av
hanterare i denna fil är en delmängd av mängden i cgroup.controllers för denna styrgrupp.
Uppsättningen av aktiva hanterare modifieras genom att till denna fil skriva strängar som
innehåller blankavgränsade hanterarnamn, vart och ett föregånget av ”+” (för att aktivera
hanteraren) eller ”-” (för att avaktivera hanteraren), som i följande exempel:
echo '+pids -memory' > x/y/cgroup.subtree_control
Ett försök att aktivera en hanterare som inte finns i cgroup.controllers medför ett fel ENOENT när
man skriver till filen cgroup.subtree_control.
Eftersom listan av hanterare i cgroup.subtree_control är en delmängd av dem i cgroup.controllers kan en
hanterare som har avaktiverats i en styrgrupp i hierarkin aldrig återaktiveras i underträdet nedanför den
styrgruppen.
En styrgrupps fil cgroup.subree_control avgör uppsättningen hanterare som används i barnstyrgruppen. När
en hanterare (t.ex., pids) finns i filen cgroup.subtree_control i en föräldrastyrgrupp, då skapas
automatiskt motsvarande hanterargränssnittsfiler (t.ex., pids.max) i barnen till den styrgruppen och kan
användas för att utöva resursstyrning i barnstyrgrupperna.
Cgroups v2 regeln ”inga interna processer”
Cgroups v2 upprätthåller en så kallad ”inga interna processer”-regel. Grovt uttryckt betyder denna regel
att, med undantag för rotstyrgruppen, processer endast får bo i lövnoder (styrgrupper som inte själva
innehåller barnstyrgrupper). Detta undviker behovet av att avgöra hur resurser skall fördelas mellan
processer som är medlemmar av en styrgrupp A och processer i barnstyrgrupper till A.
Till exempel, om styrgruppen /sg1/sg2 finns, då kan en process bo i /sg1/sg2, men inte i /sg1. Detta är
så för att undvika en tvetydighet i cgroups v1 med avseende på delegationen av resurser mellan processer
i /sg1 och dess barnstyrgrupper. Det rekommenderade sättet i cgroups v2 är att skapa en underkatalog som
heter leaf för alla styrgrupper som inte är löv, vilken skall innehålla processer men inga
barnstyrgrupper. Alltså, processer vilka tidigare skulle ha hamnat i /sg1 skulle nu hamna i /sg1/leaf.
Detta har fördelen att göra relationen mellan processer i /sg1/leaf och /sg1s andra barn explicit.
Regeln om ”inga interna processer” är i verkligheten mer subtil än den uttrycks ovan. Mer exakt är regeln
att en styrgrupp (annan än roten) inte både kan (1) ha medlemsprocesser, och (2) distribuera resurser
till barnstyrgrupper — det vill säga, ha en fil cgroup.subtree_control som inte är tom. Alltså är det
möjligt för en styrgrupp att både ha medlemsprocesser och barnstyrgrupper, men före några hanterare kan
aktiveras för den styrgruppen måste medlemsprocesserna flyttas ut ur styrgruppen (t.ex., kanske in i
barnstyrgrupperna).
Med tillägget i Linux 4.14 av ”trådat läge” (beskrivet nedan) har regeln om ”inga interna processer”
blivit friare i några fall.
Cgroups v2 fil cgroup.events
Varje styrgrupp annan än roten i v2-hierarkin innehåller en fil endast för läsning, cgroup.events, vars
innehåll är nyckel-värde-par (begränsade med nyradstecken, med nyckeln och värdet separerade med
blanktecken) som ger information om styrgruppen.
$ cat mingrp/cgroup.events
populated 1
frozen 0
Följande nycklar kan förekomma i denna fil:
populated
Värdet på denna nyckel är antingen 1, om denna styrgrupp eller någon av dess avkommor har
medlemsprocesser, annars 0.
frozen (sedan Linux 5.2)
Värdet på denna nyckel är 1 om denna styrgrupp för närvarande är frusen, eller 0 om den inte är
det.
Filen cgroup.events kan övervakas för att ta emot notifieringar när värdet på en av dess nycklar ändras.
Sådan övervakning kan göras med inotify(7), vilket notifierar om ändringar som IN_MODIFY-händelser, eller
poll(2), vilket notifierar om ändringar genom att returnera bitarna POLLPRI och POLLERR i fältet revents.
Cgroup v2 släppnotifieringar
Cgroups v2 tillhandahåller en ny mekanism för att få notifieringar när en styrgrupp blir tom. Filerna
release_agent och notify_on_release är borttagna, och ersatta av nyckeln populated i filen cgroup.events.
Denna nyckel har antingen värdet 0, vilket betyder att styrgruppen (och dess avkommor) inte innehåller
några medlemsprocesser (andra än zombier), eller 1, vilket betyder att styrgruppen (eller en av dess
avkommor) innehåller medlemsprocesser.
Mekanismen för släppnotifieringar i cgroups v2 ger följande fördelar framför mekanismen release_agent i
cgroups v1:
• Den tillåter billigare notifiering, eftersom en enda process kan övervaka flera cgroup.events-filer
(med teknikerna som beskrivs tidigare). Däremot medför mekanismen i cgroups v1 kostnaden i att skapa
en process för varje notifiering.
• Notifieringar för olika underhierarkier av styrgrupper kan delegeras till andra processer. Däremot
tillåter mekanismen i cgroups v1 endast en släppagent för en hel hierarki.
Cgroups v2 filen cgroup.stat
Varje styrgrupp i v2-hierarkin innehåller en fil cgroup.stat endast för läsning (först introducerad i
Linux 4.14) som består av rader som innehåller nyckel-värde-par. Följande nycklar finns för närvarande i
denna fil:
nr_descendants
Detta är det totala antalet synliga (d.v.s., levande) avkommestyrgrupper under denna styrgrupp.
nr_dying_descendants
Detta är det totala antalet döende avkommestyrgrupper under denna styrgrupp. En styrgrupp går in i
tillståndet döende efter att ha tagits bort. Den finns kvar i detta tillstånd under en odefinierad
period (vilken kommer bero på systemets last) medan resurser frigörs innan styrgruppen förstörs.
Observera att förekomsten av några styrgrupper i tillståndet döende är normalt och indikerar inte
något problem.
En process kan inte göras till medlem av en döende styrgrupp, och en döende styrgrupp kan inte
återupplivas.
Begränsning av antalet avkommestyrgrupper
Varje styrgrupp i v2-hierarkin innehåller följande filer, vilka kan användas för att visa och sätta
begränsningar på antalet avkommestyrgrupper under den styrgruppen:
cgroup.max.depth (sedan Linux 4.14)
Denna fil definerar en gräns på nästningsdjupet för avkommestyrgrupper. Värdet 0 i denna fil
betyder att inga avkommestyrgrupper kan skapas. Ett försök att skapa en avkomma vars nästningsnivå
överskrider gränsen misslyckas (mkdir(2) misslyckas med felet EAGAIN).
Att skriva strängen ”max” till denna fil betyder att ingen begränsning görs. Standardvärdet i
denna fil är ”max”.
cgroup.max.descendants (sedan Linux 4.14)
Denna fil definierar en gräns på antalet levande avkommestyrgrupper som denna styrgrupp får ha.
Ett försök att skapa fler avkommor än tillåtet av denna gräns misslyckas (mkdir(2) misslyckas med
felet EAGAIN).
Att skriva strängen ”max” till denna fil betyder att ingen begränsning görs. Standardvärdet i
denna fil är ”max”.
STYRGRUPPSDELEGERING: ATT DELEGERA EN HIERARKI TILL EN MINDRE PRIVILEGIERAD ANVÄNDARE
I styrgruppssammanhang betyder delegering att man överlåter hanteringen av något underträd av denna
styrgruppshierarki till en oprivilegierad användare. Cgroups v1 ger stöd för delegering baserat på
filrättigheter i styrgruppshierarkin men med mindre strikta begränsningsregler än v2 (som noteras nedan).
Cgroups v2 stödjer delegering med begränsningar genom en explicit design. Fokuset för diskussionen i
detta avsnitt är på delegering i cgroups v2, med några avvikelser för cgroups v1 nämnda längs vägen.
Lite terminologi krävs för att beskriva delegering. En delegerare är en privilegierad användare (d.v.s.,
root) som äger en föräldrastyrgrupp. En delegat är en oprivilegierad användare som kommer få
rättigheterna som behövs för att hantera någon underhierarki under föräldrastyrgruppen, känt som det
delegerade underträdet.
För att utföra en delegering gör delegeraren vissa kataloger och filer skrivbara för delegaten, typiskt
genom att ändra ägarskap på objekten till att vara användar-ID:t för delegaten. Om vi antar att vi vill
delegera hierarkin med rot vid (förslagsvis) /dlgt_grp och att det inte ännu finns några barnstyrgrupper
under den styrgruppen, då ändras ägandet av följande till användar-ID:t för delegaten:
/dlgt_grp
Att ändra ägarskap på roten till underträdet betyder att eventuella nya styrgrupper som skapas
under det underträdet (och filerna de innehåller) också kommer ägas av delegaten.
/dlgt_grp/cgroup.procs
Att ändra ägandet av den här filen betyder att delegaten kan flytta processer in i roten av det
delegerade underträdet.
/dlgt_grp/cgroup.subtree_control (endast cgroups v2)
Att ändra ägandet av den här filen betyder att delegaten kan aktivera hanterare (som finns i
/dlgt_grp/cgroup.controllers) för att vidare omfördela resurser till lägre nivåer i underträdet.
(Som ett alternativ till att ändra ägandet av denna fil kan delegeraren istället lägga till valda
hanterare till denna fil.)
/dlgt_grp/cgroup.threads (endast cgroups v2)
Att ändra ägandet av den här filen är nödvändigt om ett trådat underträd delegeras (se
beskrivningen av ”trådläge”, nedan). Detta tillåter delegaten att skriva tråd-ID:n till filen.
(Ägandet av den här filen kan även ändras när man delegerar ett domänunderträd, men för närvarande
fyller det inget syfte eftersom, vilket beskrivs nedan, det inte är möjligt att flytta en tråd
mellan domänstyrgrupper genom att skriva dess tråd-ID till filen cgroups.thread.)
I cgroups v1 är istället motsvarande fil som skall delegeras filen tasks.
Delegeraren skall inte ändra ägaren av någon annan av hanterarens gränssnittsfiler (t.ex., pids.max,
memory.high) i dlgt_grp. Dessa filer används från nästa nivå ovanför det delegerade underträdet för att
fördela resurser in i underträdet, och delegaten skall inte ha rätt att ändra resurserna som fördelas in
i det delegerade underträdet.
Se även diskussionen om filen /sys/kernel/cgroup/delegate i NOTERINGAR för information om ytterligare
delegerbara filer i cgroups v2.
Efter att de tidigare nämnda stegen har utförts kan delegaten skapa barnstyrgrupper inom det delegerade
underträdet (styrgruppens underkataloger och filerna de innehåller kommer att ägas av delegaten) och
flytta processer mellan styrgrupper i underträdet. Om några hanterare finns i
dlgt_grp/cgroup.subtree_control, eller om ägandet av den filen överläts på delegaten, kan delegaten även
styra den vidare omfördelningen av motsvarande resurser in i det delegerade underträdet.
Cgroups v2-delegering: nsdelegate och styrgruppsnamnrymder
Med start i Linux 4.13 finns det även ett andra sätt att utföra styrgruppsdelegering i cgroups
v2-hierarkin. Detta görs genom att montera eller montera om cgroups v2-filsystemet med monteringsflaggan
nsdelegate. Till exempel, om cgroup v2-filsystemet redan har monterats kan vi montera om det med flaggan
nsdelegate så här:
mount -t cgroup2 -o remount,nsdelegate \
none /sys/fs/cgroup/unified
Effekten av denna monteringsflagga är att den får styrgruppsnamnrymder att automatiskt bli
delegeringsgränser. Mer specifikt gäller följande restriktioner för processer inuti styrgruppsnamnrymden:
• Skrivningar till hanterarens gränssnittsfiler i namnrymdens rotkatalog kommer misslyckas med felet
EPERM. Processer inuti styrgruppsnamnrymden kan fortfarande skriva till delegerbara filer i
styrgruppsnamnrymdens rotkatalog såsom cgroup.procs och cgroup.subtree_control, och kan skapa
underhierarkier under rotkatalogen.
• Försök att migrera processer över namnrymdsgränsen förhindras (med felet ENOENT). Processer inuti
styrgruppsnamnrymden kan fortfarande (med hänsyn tagen till inneslutningsreglerna som beskrivs nedan)
flytta processer mellan styrgrupper inom underhierarkin under namnrymdsroten.
Möjligheten att definiera styrgruppsnamnrymder som delegeringsgränser gör styrgruppsnamnrymder mer
användbara. För att förstå varför, anta att vi redan har en styrgruppshierarki som har delegerats till en
oprivilegierad användare, cecilia, med den äldre delegeringstekniken som beskrivs ovan. Anta vidare att
cecilia vill delegera en underhierarki vidare under den befintliga delegerade hierarkin. (Till exempel
kanske den delegerade hierarkin kan vara associerad med en oprivilegierad behållare som körs av cecilia.)
Även om en styrgruppsnamnrymd användes skulle, eftersom båda hierarkierna ägs av den oprivilegierade
användaren cecilia, följande illegitima åtgärder kunna utföras.
• En process i den underliggande hierarkin skulle kunna ändra resurshanterarens inställningar i
hierarkins rotkatalog. (Dessa resurshanterares inställningar är avsedda att möjliggöra utövandet av
styrning från föräldrastyrgruppen; en process inuti barngruppen skall inte få ändra dem.)
• En process inuti den underliggande hierarkin skulle kunna flytta processer in i och ut ur den
underliggande hierarkin om styrgrupperna i den överliggande hierarkin på något sätt var synliga.
Genom att använda monteringsflaggan nsdelegate förhindras båda dessa möjligheter.
Monteringsflaggan nsdelegate har bara någon effekt när den används i den initiala monteringsnamnrymden; i
andra monteringsnamnrymder ignoreras flaggan tyst.
Observera: på en del system monterar systemd(1) automatiskt filsystemet cgroup v2. För att experimentera
med flaggan nsdelegate kan det vara användbart att starta kärnan med följande kommandoradsflaggor:
cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller
Dessa flaggor får kärnan att starta med cgroups v1-hanterarna avaktiverade (vilket betyder att hanterarna
finns tillgängliga i v2-hierarkin), och säger till systemd(1) att inte montera och använda cgroup
v2-hierarkin, så att v2-hierarkin kan monteras manuellt med de önskade flaggorna efter uppstart.
Inneslutningsregler för styrgruppsdelegering
Några inneslutningsregler för delegering säkerställer att delegaten kan flytta processer mellan
styrgrupper inom det delegerade underträdet, men inte kan flytta processer utifrån det delegerade
underträdet in i underträdet eller vice versa. En oprivilegierad process (d.v.s., delegaten) kan skriva
PID:en för en ”mål”-process in i en fil cgroup.procs endast om alla följande är sanna:
• Skrivaren har skrivrättigheter på filen cgroup.procs i målstyrgruppen.
• Skrivaren har skrivrättigheter till filen cgroup.procs i den närmaste gemensamma anfadern till käll-
och målstyrgrupperna. Observera att i några fall kan den närmaste anfadern vara käll- eller
målstyrgruppen själv. Detta krav vidmakthålls inte för cgroups v1-hierarkier, med konsekvensen att
inneslutningen i v1 är mindre strikt än i v2. (Till exempel kan i cgroups v1 användaren som äger två
distinkta delegerade underhierarkier flytta en process mellan hierarkierna.)
• Om cgroup v2-filsystemet monterades med flaggan nsdelegate måste skrivaren kunna se käll- och
målstyrgrupperna från sin egen styrgruppsnamnrymd.
• I cgroups v1: skrivarens effektiva UID (d.v.s., delegaten) matchar målprocessens verkliga användar-ID
eller sparade set-user-ID. Före Linux 4.11 gällde detta krav även i cgroups v2. (Detta var ett
historiskt krav ärvt från cgroups v1 som senare bedömdes som onödigt, eftersom de andra reglerna
räcker för inneslutning i cgroups v2.)
Observera: en konsekvens av dessa inneslutningsreger för delegering är att den oprivilegierade delegaten
inte kan placera in den första processen i det delegerade underträdet; istället måste delegeraren placera
in den första processen (en process som ägs av delegaten) i det delegerade underträdet.
CGROUPS VERSION 2 TRÅDLÄGE
Bland restriktionerna som åläggs av cgroups v2 och som inte fanns med i cgroups v1 är följande:
• Ingen styrning på trådnivå: alla trådarna i en process måste finnas i samma styrgrupp.
• Inga interna processer: en styrgrupp kan inte både ha medlemsprocesser och utöva styrning av
barnstyrgrupper.
Båda dessa restriktioner lades till för att avsaknaden av dessa restriktioner hade orsakat problem i
cgroups v1. Speciellt var möjligheten i cgroups v1 att tillåta upplösning på trådnivå av
styrgruppsmedlemskap inte meningsfull för några hanterare. (Ett noterbart exempel var hanteraren memory:
eftersom trådar delar en adressrymd är det inte meningsfullt att dela trådar mellan olika
memory-styrgrupper.)
Oaktat det ursprungliga designbeslutet i cgroups v2 fanns det användningsfall för vissa hanterare,
särskilt hanteraren cpu, för vilka upplösning av styrningen på trådnivå var meningsfull och användbar.
För att rymma sådana fall lade Linux 4.14 till trådläge till cgroups v2.
Trådläge tillåter följande:
• Att skapa trådade underträd i vilka en process trådar kan spridas mellan styrgrupper inuti trädet.
(Ett trådunderträd kan innehålla flera multitrådade processer.)
• Begreppet trådade hanterare vilka kan fördela resurser mellan styrgrupperna i ett trådat underträd.
• Lättandet av ”regeln inga interna processer”, så att en styrgrupp kan, inom ett trådat underträd, både
innehålla medlemstrådar och utöva resurshantering mellan barnstyrgrupper.
Med tillägget av trådläge innehåller numera varje styrgrupp utom roten en ny fil, cgroup.type, som visar,
och under vissa omständigheter kan användas för att ändra, en styrgrupps ”typ”. Denna fil innehåller ett
av följande typvärden:
domain Detta är en normal v2-styrgrupp som tillhandahåller styrning på processnivå. Om en process är
medlem av denna styrgrupp, då är alla processens trådar (per definition) i samma styrgrupp. Detta
är standardtypen för styrgrupper, och ger samma beteende som gavs för styrgrupper i den
ursprungliga implementationen av cgroups v2.
threaded
Denna styrgrupp är medlem i ett trådat underträd. Trådar kan läggas till till denna styrgrupp, och
hanterare kan aktiveras för styrgruppen.
domain threaded
Detta är en domänstyrgrupp som tjänstgör som roten i ett trådat underträd. Denna styrgruppstyp är
även känd som ”trådad rot”.
domain invalid
Detta är en styrgrupp inuti ett trådat underträd som är i ett ”felaktigt” tillstånd. Processer kan
inte läggas till till styrgruppen, och hanterare kan inte aktiveras för styrgruppen. Det enda man
kan göra med denna styrgrupp (bortsett från att ta bort den) är att konvertera den till en trådad
styrgrupp genom att skriva strängen ”threaded” till filen cgroup.type.
Motiveringen till existensen av denna ”provisoriska” typ under skapandet av ett trådat underträd
(istället för att kärnan helt enkelt omedelbart konverterar alla styrgrupper under en trådad rot
till typen trådad) är att ge utrymme för möjliga framtida utökningar av modellen för trådat läge.
Trådade hanterare kontra domänhanterare
I och med tillägget av trådat läge särskiljer cgroups v2 nu två typer av resurshanterare:
• Trådade hanterare: dessa hanterare stödjer resursstyrning på trådnivå och kan aktiveras inuti trådade
underträd, med resultatet att motsvarande hanterargränssnittsfiler dyker upp inuti styrgrupperna i det
trådade underträdet. Från och med Linux 4.19 är följande hanterare trådade: cpu, perf_event och pids.
• Domänhanterare: dessa hanterare stödjer endast resursstyrning på processnivå. Från en domänhanterares
perspektiv är alla trådar i en process alltid i samma styrgrupp. Domänhanterare kan inte aktiveras
inuti ett trådat underträd.
Att skapa ett trådat underträd
Det finns två vägar som leder till att ett trådat underträd skapas. Den första vägen är som följer:
(1) Vi skriver strängen ”threaded” till filen cgroup.type i en styrgrupp y/z som just nu har typen
domän. Detta har följande effekter:
• Typen på styrgruppen y/z blir trådad.
• Föräldrastyrgruppens, y, typ blir domän trådad. Föräldrastyrgruppen är roten i ett trådat
underträd (även känt som ”trådad rot”).
• Alla andra styrgrupper under y som inte redan hade typen trådad (för att de befann sig inuti
redan befintliga trådade underträd under den nya trådade roten) konverteras till typen domän
felaktig.
(2) Vi skriver strängen ”threaded” till var och en av styrgrupperna med domän felaktig under y, för att
konvertera dem till typen trådad. Som en konsekvens av detta steg har nu alla trådar under den
trådade roten typen trådad och det trådade trädet är därmed fullt användbart. Kravet att skriva
”threaded” till var och en av dessa styrgrupper är något otymplig, men möjliggör tänkbara framtida
utvidgningar av modellen trådläge.
Den andra vägen att skapa ett trådat underträd är som följer:
(1) I en befintlig styrgrupp, z, som just nu har typen domän aktiverar vi (1.1) en eller flera av de
trådade hanterarna och (1.2) gör en process till en medlem av z. (Dessa två steg kan göras i
godtycklig ordning.) Detta har följande konsekvenser:
• Typen på z blir domän trådad.
• Alla nedstigande styrgrupper till z som inte redan hade typen trådad konverteras till typen domän
felaktig.
(2) Som tidigare gör vi det trådade underträdet användbart genom att skriva strängen ”threaded” till var
och en av styrgrupperna med domän felaktig under y, för att konvertera dem till typen trådad.
En av konsekvenserna av de ovanstående sätten för att skapa ett trådat underträd är att den trådade
rotstyrgruppen endast kan vara förälder till styrgrupper som är trådade (och domän felaktiga). Den
trådade rotstyrgruppen kan inte vara förälder till domänstyrgrupper, och en trådad styrgrupp kan inte ha
ett syskon som är en domänstyrgrupp.
Att använda ett trådat underträd
Inom ett trådat underträd kan trådade hanterare aktiveras i varje undergrupp vars typ har ändrats till
trådad; när man gör det dyker motsvarande gränssnittsfiler för hanteraren upp i barnen till den
styrgruppen.
En process kan flyttas in i ett trådat underträd genom att skriva dess PID till filen cgroup.procs i en
av styrgrupperna inuti trädet. Detta medför att alla trådarna i den processen görs till medlemmar av
motsvarande styrgrupp och gör processen till en medlem av det trådade underträdet. Processens trådar kan
sedan spridas över det trådade underträdet genom att skriva deras tråd-ID:n (se gettid(2)) till filerna
cgroup.threads i olika styrgrupper inuti underträdet. En process alla trådar måste befinna sig i samma
trådade underträd.
Liksom när man skriver till cgroup.procs gäller vissa inneslutningsregler när man skriver till filen
cgroup.threads:
• Skrivaren måste ha skrivrättigheter till filen cgroup.threads i målstyrgruppen.
• Skrivaren måste ha skrivrättigheter till filen cgroup.procs i den gemensamma anfadern till käll- och
målstyrgrupperna. (I några fall kan den gemensamma anfadern vara käll- eller målstyrgruppen själv.)
• Käll- och målstyrgrupperna måste finnas i samma trådade underträd. (Utanför ett trådat underträd
misslyckas ett försök att flytta en tråd genom att skriva dess tråd-ID till filen cgroup.threads i en
annan domänstyrgrupp med felet EOPNOTSUPP.)
Filen cgroup.threads finns i alla styrgrupper (inklusive domänstyrgrupper) och kan läsas för att upptäcka
uppsättningen trådar som finns i styrgruppen. Uppsättningen tråd-ID:n som fås när man läser denna fil är
inte garanterat i ordning eller fri från dubbletter.
Filen cgroup.procs i den trådade roten visar PID:arna för alla processer som är medlemmar av det trådade
underträdet. Filen cgroup.procs i de andra styrgrupperna i underträdet är inte läsbara.
Domänhanterare kan inte aktiveras i ett trådat underträd; inga gränssnittsfiler till hanteraren dyker upp
i styrgrupperna under den trådade roten. Från domänhanterarens synvinkel är trådade underträd osynliga:
en multitrådad process i ett trådat underträd ser för domänhanteraren ut som en process som bor i den
trådade rotstyrgruppen.
Inom ett trådat underträd gäller inte regeln ”inga interna processer”: en styrgrupp kan både innehålla
medlemsprocesser (eller -trådar) och utöva styrning över barnstyrgrupper.
Regler för att skriva till cgroup.type och att skapa trådade underträd
Ett antal regler gäller vid skrivning till filen cgroup.type:
• Endast strängen ”threaded” får skrivas. Med andra ord, den enda uttryckliga övergången som är möjlig
är att konvertera en domänstyrgrupp till typen trådad.
• Resultatet av att skriva ”threaded” beror på det nuvarande värdet i cgroup.type enligt följande:
• Domän eller domän trådad: inled skapandet av ett trådat underträd (vars rot är föräldern till denna
styrgrupp) via det första av sätten som beskrivs ovan;
• Domän felaktig: konvertera denna styrgrupp (vilken finns inuti ett trådat underträd) till ett
användbart (d.v.s., trådat) tillstånd;
• Trådad: ingen effekt (en ”no-op”).
• Vi kan inte skriva till en cgroup.type-fil om förälderns typ är domän felaktig. Med andra ord,
styrgruppen i ett trådat underträd måste konverteras till tillståndet trådad uppifrån och ner.
Det finns även några begränsningar som måste vara uppfyllda för att skapa ett trådat underträd rotat i
styrgruppen x:
• Det får inte finnas någon medlemsprocess i nedstigande styrgrupper från x. (Styrgruppen x själv kan ha
medlemsprocesser.)
• Inga domänhanterare får vara aktiverade i xs fil cgroup.subtree_control.
Vid brott mot någon av ovanstående begränsningar kommer försök att skriva ”threaded” till en fil
cgroup.type att misslyckas med felet ENOTSUP.
Styrgruppstypen ”domän trådad”
Enligt metoderna som beskrivs ovan kan typen på en styrgrupp ändras till domän trådad i endera av
följande fall:
• Strängen ”threaded” skrivs till en barnstyrgrupp.
• En trådad hanterare aktiveras inuti styrgruppen och en process görs till medlem av styrgruppen.
En domän trådad styrgrupp, x, kan återgå till typen domän om ovanstående villkor inte längre är uppfyllda
— det vill säga, om alla trådade barnstyrgrupper till x tas bort och antingen x inte längre har trådade
hanterare aktiverade eller inte längre har medlemsprocesser.
När en styrgrupp x som är domän trådad återgår till typen domän:
• Alla avkommor till x som är domän felaktig och som inte är i underliggande trådade underträd återgår
till typen domän.
• Rotstyrgruppen i eventuella underliggande trådade underträd återgår till typen domän trådad.
Undantag för rotstyrgruppen
Rotstyrgruppen i v2-hierarkin hanteras speciellt: den kan vara förälder till både domän och trådade
styrgrupper. Om strängen ”threaded” skrivs till filen cgroup.type i en av barnen till rotstyrgruppen, då
• blir typen på den styrgruppen trådad.
• ändras typen på avkommor till den styrgruppen som inte är en del av underliggande trådade underträd
till domän felaktig.
Observera att i detta fall finns det ingen styrgrupp vars typ blir domän trådad. (Teoretiskt sett kan
rotstyrgruppen betraktas som den trådade roten till styrgruppen vars typ ändrades till trådad.)
Syftet med denna speciella hantering av rotstyrgruppen är att låta en trådad styrgrupp som använder
hanteraren cpu att placeras så högt som möjligt i hierarkin, för att minimera den (lilla) kostnaden i att
traversera styrgruppshierarkin.
Hanteraren ”cpu” i cgroups v2 och realtidstrådar
Per Linux 4.19 stödjer inte hanteraren cpu i cgroups v2 styrning av realtidstrådar (specifikt trådar
schemalagda under någon av policyerna SCHED_FIFO, SCHED_RR och SCHED_DEADLINE; se sched(7)). Därför kan
hanteraren cpu aktiveras i rotstyrgruppen endast om alla realtidstrådar finns i rotstyrgruppen. (Om det
finns realtidstrådar i andra styrgrupper än roten, då misslyckas ett anrop av write(2) med strängen
”+cpu” till filen cgroup.subtree_control med felet EINVAL.)
På vissa system placerar systemd(1) vissa realtidstrådar i andra styrgrupper än roten i v2-hierarkin. På
sådana system måste dessa trådar först flyttas till rotstyrgruppen innan cpu-hanteraren kan aktiveras.
FEL
Följande fel kan förekomma för mount(2):
EBUSY Ett försök att montera ett styrgruppsfilsystem för version 1 som inte specificerade vare sig
flaggan name= (för att montera en namngiven hierarki) eller ett hanterarnamn (eller all).
NOTERINGAR
En barnprocess som skapas via fork(2) ärver sin förälders styrgruppsmedlemskap. En process
styrgruppsmedlemskap bevaras över execve(2).
Flaggan CLONE_INTO_CGROUP till clone3(2) kan användas för att skapa en barnprocess som inleder sitt liv i
en annan version-2-styrgrupp än föräldraprocessen.
/proc-filer
/proc/cgroups (sedan Linux 2.6.24)
Denna fil innehåller information om hanterarna som är inkompilerade i kärnan. Ett exempel på
innehållet i denna fil (omformaterat för läsbarhet) är följande:
#subsys_name hierarchy num_cgroups enabled
cpuset 4 1 1
cpu 8 1 1
cpuacct 8 1 1
blkio 6 1 1
memory 3 1 1
devices 10 84 1
freezer 7 1 1
net_cls 9 1 1
perf_event 5 1 1
net_prio 9 1 1
hugetlb 0 1 0
pids 2 1 1
Fälten i denna fil är, från vänster till höger:
[1] Namnet på hanteraren.
[2] Det unika ID:t för styrgruppshierarkin på vilken denna hanterare är monterad. Om flera
cgroups v1-hanterare är bundna till samma hierarki kommer var och en visa samma hierarki-ID i
detta fält. Värdet i detta fält kommer vara 0 om:
• hanteraren inte är monterad på en cgroups v1-hierarki;
• hanteraren är bunden till cgroups v2s enda unifierade hierarki eller
• hanteraren är avaktiverad (se nedan).
[3] Antalet styrgrupper i denna hierarki som använder denna hanterare.
[4] Detta fält har värdet 1 om denna hanterare är aktiverad eller 0 om den har avaktiverats (via
parametern cgroup_disable på kärnans kommandorad vid uppstart).
/proc/[pid]/cgroup (sedan Linux 2.6.24)
Denna fil beskriver styrgrupperna till vilken processen med motsvarande PID hör. Den visade
informationen skiljer mellan hierarkierna för styrgrupper version 1 och version 2.
För varje styrgruppshierarki i vilken processen är medlem finns det en post som innehåller tre
kolonseparerade fält:
hierarki-ID:hanterarlista:styrgruppssökväg
Till exempel:
5:cpuacct,cpu,cpuset:/daemons
De kolonseparerade fälten är, från vänster till höger:
[1] För version 1-hierarkier av styrgrupper innehåller detta fält ett unikt hierarki-ID-nummer
som kan matchas med ett hierarki-ID i /proc/cgroups. För version 2-hierarkin av styrgrupper
innehåller detta fält värdet 0.
[2] För version 1-hierarkier av styrgrupper innehåller detta fält en kommaseparerad lista över
hanterare bundna till hierarkin. För version 2-hierarkin av styrgrupper är detta fält tomt.
[3] Detta fält innehåller sökvägen till styrgruppen i hierarkin den hör till. Sökvägen är relativ
hierarkins monteringspunkt.
/sys/kernel/cgroup-filer
/sys/kernel/cgroup/delegate (sedan Linux 4.15)
Denna fil exporterar en lista över filerna i cgroups v2 (en per rad) som går att delegera (d.v.s.,
vars ägarskap skall ändras till delegatens användar-ID). I framtiden kan uppsättningen delegerbara
filer ändras eller växa, och denna fil ger en möjlighet för kärnan att informera program i
användarrymden om vilka filer som måste delegeras. Per Linux 4.15 syns följande när man
inspekterar filen:
$ cat /sys/kernel/cgroup/delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads
/sys/kernel/cgroup/features (sedan Linux 4.15)
Med tiden kan samlingen av funktioner i cgroups v2 som kärnan tillhandahåller ändras eller växa,
och några funktionerna kanske inte aktiveras som standard. Denna fil ger ett sätt för program i
användarrymden att avgöra vilka funktioner den körande kärnan stödjer och har aktiverade.
Funktioner listas en per rad:
$ cat /sys/kernel/cgroup/features
nsdelegate
memory_localevents
Posterna som kan förekomma i denna fil är:
memory_localevents (sedan Linux 5.2)
Kärnan stödjer monteringsflaggan memory_localevents.
nsdelegate (sedan Linux 4.15)
Kärnan stödjer monteringsflaggan nsdelegate.
memory_recursiveprot (sedan Linux 5.7)
Kärnan stödjer monteringsflaggan memory_recursiveprot.
SE ÄVEN
prlimit(1), systemd(1), systemd-cgls(1), systemd-cgtop(1), clone(2), ioprio_set(2), perf_event_open(2),
setrlimit(2), cgroup_namespaces(7), cpuset(7), namespaces(7), sched(7), user_namespaces(7)
Kärnans källfil Documentation/admin-guide/cgroup-v2.rst.
ÖVERSÄTTNING
Den svenska översättningen av denna manualsida skapades av Göran Uddeborg <goeran@uddeborg.se>
Denna översättning är fri dokumentation; läs GNU General Public License Version 3 eller senare för
upphovsrättsvillkor. Vi tar INGET ANSVAR.
Om du hittar fel i översättningen av denna manualsida, skicka ett mail till Tp-sv@listor.tp-sv.se.
Linux man-pages 6.03 5 februari 2023 cgroups(7)