Usando Systemd para Gerenciar Grupos de Controle

Esta seção analisa a maneira como systemd inicialmente divide cada um dos controladores de kernel padrão, por exemplo, CPU, memory e blkio, em partes chamadas "segmentos", conforme ilustrado pelo seguinte exemplo de gráfico de pizza:

Como mostra o gráfico de pizza anterior, por padrão, cada controlador de recursos é dividido igualmente entre as 3 fatias a seguir:

• Sistema (system.slice).

• Usuário (user.slice).

• Máquina (machine.slice).

A lista a seguir analisa cada fatia mais de perto. Para fins de discussão, os exemplos na lista se concentram no controlador da CPU.

Sistema (system.slice)

Este segmento de recurso é usado para gerenciar a alocação de recursos entre daemons e unidades de serviço.

Conforme mostrado no exemplo de gráfico de pizza anterior, o segmento do sistema é dividido em subsegmentos adicionais. Por exemplo, no caso de recursos de CPU, podemos ter alocações de subsegmento no segmento do sistema que incluem o seguinte:

• httpd.service (CPUWeight=100)

• sshd.service (CPUWeight =100)

• crond.service (CPUWeight =100)

• app1.service (CPUWeight =100)

• app2.service (CPUWeight =100)

Na lista anterior, app1.service e app2.service representam serviços de aplicativo personalizados que podem ser executados no sistema.

Usuário (user.slice)

Esta fatia de recurso é usada para gerenciar a alocação de recursos entre as sessões do usuário. Um único segmento é criado para cada UID independentemente de quantos logins o usuário associado tenha ativo no servidor. Continuando com nosso exemplo de gráfico de pizza, os subsegmentos podem ser os seguintes:

• user1 (CPUWeight=100, UID=982)

• user2 (CPUWeight=100, UID=1001)

Máquina (machine.slice)

Essa fatia do recurso é usada para gerenciar a alocação de recursos entre máquinas virtuais hospedadas, como convidados KVM e Contêineres Linux. A fatia da máquina só está presente em um servidor se o servidor estiver hospedando máquinas virtuais ou Linux Containers.

A analogia do gráfico de pizza usada nas seções anteriores é uma maneira útil de conceituar a divisão de recursos em fatias. No entanto, em termos de organização estrutural, os grupos de controle são organizados em uma hierarquia. Você pode exibir a hierarquia de grupos de controle systemd no sistema executando o comando systemd-cgls da seguinte forma:

systemd-cgls

Control group /:
-.slice
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ ├─user-982.slice (#4131)
│ │ → user.invocation_id: 9d0d94d7b8a54bcea2498048911136c8
│ │ ├─session-c1.scope (#4437)
│ │ │ ├─2416 /usr/bin/sudo -u ocarun /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ │ └─2494 /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ └─user@982.service … (#4199)
│ │   → user.delegate: 1
│ │   → user.invocation_id: 37c7aed7aa6e4874980b79616acf0c82
│ │   └─init.scope (#4233)
│ │     ├─2437 /usr/lib/systemd/systemd --user
│ │     └─2445 (sd-pam)
│ └─user-1001.slice (#7225)
│   → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│   ├─session-2.scope (#7463)
│   │ ├─20304 sshd: oracle [priv]
│   │ ├─20404 sshd: oracle@pts/0
│   │ ├─20405 -bash
│   │ ├─20441 systemd-cgls
│   │ └─20442 less
│   └─user@1001.service … (#7293)
│     → user.delegate: 1
│     → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     └─init.scope (#7327)
│       ├─20395 /usr/lib/systemd/systemd --user
│       └─20397 (sd-pam)
├─init.scope (#19)
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 28
└─system.slice (#53)
 ...
  ├─dbus-broker.service (#2737)
  │ → user.invocation_id: 2bbe054a2c4d49809b16cb9c6552d5a6
  │ ├─1450 /usr/bin/dbus-broker-launch --scope system --audit
  │ └─1457 dbus-broker --log 4 --controller 9 --machine-id 852951209c274cfea35a953ad2964622 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
 ...
  ├─chronyd.service (#2805)
  │ → user.invocation_id: e264f67ad6114ad5afbe7929142faa4b
  │ └─1482 /usr/sbin/chronyd -F 2
  ├─auditd.service (#2601)
  │ → user.invocation_id: f7a8286921734949b73849b4642e3277
  │ ├─1421 /sbin/auditd
  │ └─1423 /usr/sbin/sedispatch
  ├─tuned.service (#3349)
  │ → user.invocation_id: fec7f73678754ed687e3910017886c5e
  │ └─1564 /usr/bin/python3 -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service (#1837)
  │ → user.invocation_id: bf7fb22ba12f44afab3054aab661aedb
  │ └─1068 /usr/lib/systemd/systemd-journald
  ├─atd.service (#3961)
  │ → user.invocation_id: 1c59679265ab492482bfdc9c02f5eec5
  │ └─2146 /usr/sbin/atd -f
  ├─sshd.service (#3757)
  │ → user.invocation_id: 57e195491341431298db233e998fb180
  │ └─2097 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─crond.service (#3995)
  │ → user.invocation_id: 4f5b380a53db4de5adcf23f35d638ff5
  │ └─2150 /usr/sbin/crond -n
  ...

O exemplo de saída anterior mostra como todos os grupos de controle "*.slice" residem no segmento raiz -.slice. Abaixo do segmento raiz, você pode ver os grupos de controle user.slice e system.slice, cada um com seus próprios subsegmentos cgroup filhos.

Examinando a saída do comando systemd-cgls , você pode ver como, exceto para a raiz -.slice, todos os processos estão nos nós folha. Este acordo é aplicado pelo cgroups v2, em uma regra chamada regra "nenhum processo interno". Consulte cgroups (7) para obter mais informações sobre a regra "nenhum processo interno".

A saída no exemplo de comando systemd-cgls anterior também mostra como as fatias podem ter grupos de controle filho descendentes que são escopos systemd. Os escopos systemd são revisados na seção a seguir.

O escopo systemd é um tipo de unidade systemd que agrupa os processos do service worker do sistema que foram iniciados independentemente de systemd. As unidades de escopo são transientes cgroups criados programaticamente usando as interfaces de barramento de systemd.

Por exemplo, no código de amostra a seguir, o usuário com UID 1001 executou o comando systemd-cgls e a saída mostra que session-2.scope foi criado para processos que o usuário gerou independentemente de systemd (incluindo o processo para o próprio comando, 21380 sudo systemd-cgls):

sudo systemd-cgls

Working directory /sys/fs/cgroup:
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ → trusted.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
...
│ └─user-1001.slice (#7225)
│   → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│   → trusted.invocation_id: ce93ad5f5299407e9477964494df63b7
│   ├─session-2.scope (#7463)
│   │ ├─20304 sshd: oracle [priv]
│   │ ├─20404 sshd: oracle@pts/0
│   │ ├─20405 -bash
│   │ ├─21380 sudo systemd-cgls
│   │ ├─21382 systemd-cgls
│   │ └─21383 less
│   └─user@1001.service … (#7293)
│     → user.delegate: 1
│     → trusted.delegate: 1
│     → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     → trusted.invocation_id: 70284db060c1476db5f3633e5fda7fba
│     └─init.scope (#7327)
│       ├─20395 /usr/lib/systemd/systemd --user
│       └─20397 (sd-pam)