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
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.