Red Hat Training

A Red Hat training course is available for RHEL 8

Managing, monitoring, and updating the kernel

Red Hat Enterprise Linux 8

Um guia para gerenciar o kernel do Linux no Red Hat Enterprise Linux 8

Resumo

Este documento fornece aos usuários e administradores as informações necessárias sobre a configuração de suas estações de trabalho no nível do kernel Linux. Tais ajustes trazem melhorias de desempenho, solução de problemas mais fácil ou sistema otimizado.

Tornando o código aberto mais inclusivo

A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.

Fornecendo feedback sobre a documentação da Red Hat

Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-la. Para fazer isso:

  • Para comentários simples sobre passagens específicas:

    1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML. Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
    2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
    3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
    4. Siga as instruções apresentadas.

  • Para enviar comentários mais complexos, crie um bilhete Bugzilla:

    1. Ir para o site da Bugzilla.
    2. Como Componente, use Documentation.
    3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
    4. Clique em Submit Bug.

Capítulo 1. O RPM do kernel Linux

As seções seguintes descrevem o pacote RPM do kernel Linux fornecido e mantido pela Red Hat.

1.1. O que é um RPM

Um pacote RPM é um arquivo contendo outros arquivos e seus metadados (informações sobre os arquivos que são necessários ao sistema).

Especificamente, um pacote de RPM consiste no arquivo cpio.

O arquivo cpio contém:

  • Arquivos

  • Cabeçalho RPM (metadados do pacote)

    O gerenciador de pacotes rpm utiliza estes metadados para determinar as dependências, onde instalar arquivos e outras informações.

Tipos de pacotes de RPM

Há dois tipos de pacotes de RPM. Ambos os tipos compartilham o formato do arquivo e as ferramentas, mas têm conteúdos diferentes e servem a propósitos diferentes:

  • Fonte RPM (SRPM)

    Um SRPM contém o código fonte e um arquivo SPEC, que descreve como construir o código fonte em um RPM binário. Opcionalmente, os patches para o código-fonte também são incluídos.

  • RPM Binário

    Um RPM binário contém os binários construídos a partir das fontes e remendos.

1.2. A visão geral do pacote RPM do kernel Linux

O kernel RPM é um meta pacote que não contém nenhum arquivo, mas assegura que os seguintes sub-pacotes estejam devidamente instalados:

  • kernel-core - contém um número mínimo de módulos de kernel necessários para a funcionalidade central. Este sub-pacote sozinho poderia ser usado em ambientes virtualizados e em nuvem para fornecer um kernel Red Hat Enterprise Linux 8 com um tempo de inicialização rápido e um tamanho de disco pequeno.
  • kernel-modules - contém outros módulos do kernel.
  • kernel-modules-extra - contém módulos de kernel para hardware raro.

O pequeno conjunto de sub-pacotes kernel acima visa fornecer uma superfície de manutenção reduzida aos administradores de sistemas, especialmente em ambientes virtualizados e nebulosos.

Os outros pacotes de kernel comuns são, por exemplo:

  • kernel-debug - Contém um kernel com numerosas opções de depuração habilitadas para o diagnóstico do kernel, às custas de um desempenho reduzido.
  • kernel-tools - Contém ferramentas para manipular o kernel Linux e documentação de suporte.
  • kernel-devel - Contém os cabeçalhos e os arquivos de kernel suficientes para construir módulos contra o pacote kernel.
  • kernel-abi-whitelists - Contém informações relativas ao kernel ABI do Red Hat Enterprise Linux, incluindo uma lista de símbolos do kernel que são necessários para os módulos externos do kernel Linux e um plug-in yum para ajudar na fiscalização.
  • kernel-headers - Inclui os arquivos de cabeçalho C que especificam a interface entre o kernel Linux e as bibliotecas e programas de espaço do usuário. Os arquivos de cabeçalho definem estruturas e constantes que são necessárias para a construção da maioria dos programas padrão.

1.3. Exibição do conteúdo do pacote do kernel

O procedimento seguinte descreve como visualizar o conteúdo do pacote do kernel e seus sub-pacotes sem instalá-los usando o comando rpm.

Pré-requisitos

  • Obtido kernel, kernel-core, kernel-modules, kernel-modules-extra Pacotes de RPM para sua arquitetura de CPU

Procedimento

  • Listar módulos para kernel: 

    $ rpm -qlp <kernel_rpm>
(contains no files)
…​

  • Listar módulos para kernel-core: 

    $ rpm -qlp <kernel-core_rpm>
…​
/lib/modules/4.18.0-80.el8.x86_64/kernel/fs/udf/udf.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/fs/xfs
/lib/modules/4.18.0-80.el8.x86_64/kernel/fs/xfs/xfs.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/kernel
/lib/modules/4.18.0-80.el8.x86_64/kernel/kernel/trace
/lib/modules/4.18.0-80.el8.x86_64/kernel/kernel/trace/ring_buffer_benchmark.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/lib
/lib/modules/4.18.0-80.el8.x86_64/kernel/lib/cordic.ko.xz
…​

  • Listar módulos para kernel-modules: 

    $ rpm -qlp <kernel-modules_rpm>
…​
/lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/mlx5/mlx5_ib.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/qedr/qedr.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/usnic/usnic_verbs.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/vmw_pvrdma/vmw_pvrdma.ko.xz
…​

  • Listar módulos para kernel-modules-extra: 

    $ rpm -qlp <kernel-modules-extra_rpm>
…​
/lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_cbq.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_choke.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_drr.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_dsmark.ko.xz
/lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_gred.ko.xz
…​

Recursos adicionais

  • Para informações sobre como usar o comando rpm em kernel RPM já instalado, incluindo seus sub-pacotes, consulte a página do manual rpm(8).
  • Introdução a RPM packages

Capítulo 2. Atualização do kernel com yum

As seções seguintes trazem informações sobre o kernel Linux fornecido e mantido pela Red Hat (kernel da Red Hat), e como manter o kernel da Red Hat atualizado. Como conseqüência, o sistema operacional terá todas as últimas correções de bugs, melhorias de desempenho e patches, garantindo compatibilidade com novos hardwares.

2.1. O que é o cerne

O kernel é uma parte central de um sistema operacional Linux, que gerencia os recursos do sistema, e fornece interface entre aplicações de hardware e software. O kernel da Red Hat é um kernel personalizado baseado no kernel da linha principal do upstream Linux que os engenheiros da Red Hat desenvolvem e endurecem com foco na estabilidade e compatibilidade com as mais recentes tecnologias e hardware.

Antes que a Red Hat lance uma nova versão do kernel, o kernel precisa passar por um conjunto de rigorosos testes de garantia de qualidade.

Os núcleos da Red Hat são embalados no formato RPM para que sejam fáceis de serem atualizados e verificados pelo yum gerente de pacotes.

Atenção

Os núcleos que não foram compilados pela Red Hat são not suportados pela Red Hat.

2.2. O que é yum

Esta seção se refere à descrição do yum package manager.

Recursos adicionais

2.3. Atualização do miolo

O procedimento a seguir descreve como atualizar o kernel usando o yum gerente de pacotes.

Procedimento

  1. Para atualizar o kernel, use o seguinte: 

    # yum update kernel

    Este comando atualiza o kernel junto com todas as dependências para a última versão disponível.

  2. Reinicie seu sistema para que as mudanças entrem em vigor.
Nota

Ao atualizar do Red Hat Enterprise Linux 7 para o Red Hat Enterprise Linux 8, siga as seções relevantes do Upgrading from RHEL 7 to RHEL 8 documento.

2.4. Instalando o miolo

O seguinte procedimento descreve como instalar novos núcleos utilizando o yum gerente de pacotes.

Procedimento

  • Para instalar uma versão específica do kernel, use o seguinte: 

    # yum install kernel-{version}

Recursos adicionais

  • Para uma lista dos grãos disponíveis, consulte Red Hat Code Browser.
  • Para uma lista de datas de lançamento de versões específicas do kernel, veja this article.

Capítulo 3. Gerenciando módulos do núcleo

As seções seguintes explicam o que são módulos do kernel, como exibir suas informações e como realizar tarefas administrativas básicas com módulos do kernel.

3.1. Introdução aos módulos do kernel

O kernel do Red Hat Enterprise Linux pode ser estendido com partes adicionais opcionais de funcionalidade, chamadas módulos do kernel, sem a necessidade de reiniciar o sistema. No Red Hat Enterprise Linux 8, os módulos do kernel são código de kernel extra que é embutido em arquivos objetos comprimidos <KERNEL_MODULE_NAME>.ko.xz.

As funcionalidades mais comuns habilitadas pelos módulos do kernel são:

  • Driver de dispositivo que adiciona suporte para novo hardware
  • Suporte para um sistema de arquivo como GFS2 ou NFS
  • Chamadas de sistema

Em sistemas modernos, os módulos do kernel são automaticamente carregados quando necessário. Entretanto, em alguns casos, é necessário carregar ou descarregar os módulos manualmente.

Como o próprio núcleo, os módulos podem tomar parâmetros que personalizam seu comportamento, se necessário.

São fornecidas ferramentas para inspecionar quais módulos estão funcionando atualmente, quais módulos estão disponíveis para carregar no kernel e quais parâmetros um módulo aceita. O ferramental também fornece um mecanismo para carregar e descarregar módulos do kernel para o kernel em execução.

3.2. Introdução à especificação do carregador de inicialização

A Especificação BootLoader (BLS) define um esquema e o formato de arquivo para gerenciar a configuração do bootloader para cada opção de boot no diretório drop-in sem a necessidade de manipular os arquivos de configuração do bootloader. Ao contrário das abordagens anteriores, cada entrada de boot é agora representada por um arquivo de configuração separado no diretório drop-in. O diretório suspenso estende sua configuração sem ter a necessidade de editar ou regenerar os arquivos de configuração. O BLS estende este conceito para as entradas do menu de inicialização.

Usando o BLS, você pode gerenciar as opções do menu bootloader adicionando, removendo ou editando arquivos individuais de entrada de boot em um diretório. Isto torna o processo de instalação do kernel significativamente mais simples e consistente entre as diferentes arquiteturas.

A ferramenta grubby é um roteiro de embalagem fina em torno do BLS e suporta os mesmos argumentos e opções grubby. Ela roda o dracut para criar uma imagem inicial do ramdisk. Com esta configuração, os arquivos de configuração do núcleo do bootloader são estáticos e não são modificados após a instalação do kernel.

Esta premissa é particularmente relevante no Red Hat Enterprise Linux 8 porque o mesmo bootloader não é usado em todas as arquiteturas. GRUB2 é usado na maioria delas como o ARM de 64 bits, mas variantes poucoendianas do IBM Power Systems com camada aberta de abstração de energia (OPAL) usa Petitboot e a arquitetura IBM Z usa zipl.

Recursos adicionais

3.3. Dependências do módulo Kernel

Certos módulos do núcleo às vezes dependem de um ou mais outros módulos do núcleo. O arquivo /lib/modules/<KERNEL_VERSION>/modules.dep contém uma lista completa das dependências dos módulos do kernel para a respectiva versão do kernel.

O arquivo de dependência é gerado pelo programa depmod, que é uma parte do pacote kmod. Muitas das utilidades fornecidas por kmod levam em conta as dependências dos módulos ao realizar operações, de modo que raramente é necessário o rastreamento de dependência manual.

Atenção

O código dos módulos do kernel é executado no kernel-space no modo irrestrito. Por causa disso, você deve estar atento a quais módulos você está carregando.

Recursos adicionais

  • Para mais informações sobre /lib/modules/<KERNEL_VERSION>/modules.dep, consulte a página do manual modules.dep(5).
  • Para mais detalhes, incluindo a sinopse e as opções de depmod, consulte a página do manual depmod(8).

3.4. Listagem dos módulos do kernel atualmente carregados

O procedimento seguinte descreve como visualizar os módulos do kernel atualmente carregados.

Pré-requisitos

  • O pacote kmod está instalado.

Procedimento

  • Para listar todos os módulos do kernel atualmente carregados, execute: 

    $ lsmod

Module                  Size  Used by
fuse                  126976  3
uinput                 20480  1
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  1
xt_conntrack           16384  1
ipt_REJECT             16384  1
nft_counter            16384  16
nf_nat_tftp            16384  0
nf_conntrack_tftp      16384  1 nf_nat_tftp
tun                    49152  1
bridge                192512  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
nf_tables_set          32768  5
nft_fib_inet           16384  1
…​

    No exemplo acima:

    • A primeira coluna fornece o names dos módulos atualmente carregados.
    • A segunda coluna exibe a quantidade de memory por módulo em quilobytes.
    • A última coluna mostra o número e, opcionalmente, os nomes dos módulos que são dependent em um determinado módulo.

Recursos adicionais

  • Para mais informações sobre kmod, consulte o arquivo /usr/share/doc/kmod/README ou a página do manual lsmod(8).

3.5. Listagem de todos os kernels instalados

O procedimento seguinte descreve como usar a ferramenta de linha de comando grubby para listar as entradas de inicialização GRUB2.

Procedimento

Para listar as entradas de inicialização do kernel:

  • Para listar as entradas de inicialização do kernel, execute:

    # grubby --info=ALL | grep title

    O comando exibe as entradas de inicialização do kernel. O campo kernel mostra o caminho do kernel.

    O procedimento seguinte descreve como usar o utilitário grubby para listar todos os kernels instalados em seus sistemas usando a linha de comando do kernel.

Como exemplo, considere listar grubby-8.40-17, a partir do menu Grub2, tanto nas instalações BLS quanto nas não-BLS.

Procedimento

Para listar todos os módulos de kernel instalados:

  • Executar o seguinte comando:

    # grubby --info=ALL | grep title

    A lista de todos os kernels instalados é exibida da seguinte forma: 

    title=Red Hat Enterprise Linux (4.18.0-20.el8.x86_64) 8.0 (Ootpa)
title=Red Hat Enterprise Linux (4.18.0-19.el8.x86_64) 8.0 (Ootpa)
title=Red Hat Enterprise Linux (4.18.0-12.el8.x86_64) 8.0 (Ootpa)
title=Red Hat Enterprise Linux (4.18.0) 8.0 (Ootpa)
title=Red Hat Enterprise Linux (0-rescue-2fb13ddde2e24fde9e6a246a942caed1) 8.0 (Ootpa)

A saída acima mostra a lista de todos os kernels instalados para grubby-8.40-17, usando o menu Grub2.

3.6. Definir um kernel como padrão

O procedimento seguinte descreve como definir um kernel específico como padrão usando a ferramenta de linha de comando grubby e GRUB2.

Procedimento

Configurando o kernel como padrão, usando a ferramenta grubby
  • Execute o seguinte comando para definir o kernel como padrão usando a ferramenta grubby:

# grubby --set-default $kernel_path

O comando usa uma identificação de máquina sem o sufixo .conf como argumento.

Nota

A identificação da máquina está localizada no diretório /boot/loader/entries/.

Definindo o kernel como padrão, usando o argumento id
  • Liste as entradas de inicialização usando o argumento id e, em seguida, defina um kernel pretendido como padrão: 
# grubby --info ALL | grep id
# grubby --set-default /boot/vmlinuz-<version>.<architecture>
Nota

Para listar as entradas de inicialização usando o argumento title, execute o # grubby --info=ALL | grep title comando.

Configurando o kernel padrão apenas para o próximo boot
  • Execute o seguinte comando para definir o kernel padrão apenas para a próxima reinicialização usando o comando grub2-reboot: 
# grub2-reboot <index|title|id>
Atenção

Defina com cuidado o kernel padrão para apenas o próximo boot. A instalação de novos kernel RPM's, kernels auto-construídos e a adição manual das entradas no diretório /boot/loader/entries/ podem alterar os valores do índice.

3.7. Exibição de informações sobre os módulos do kernel

Ao trabalhar com um módulo de kernel, você pode querer ver mais informações sobre esse módulo. Este procedimento descreve como exibir informações extras sobre os módulos do kernel.

Pré-requisitos

  • O pacote kmod está instalado.

Procedimento

  • Para exibir informações sobre qualquer módulo do kernel, execute: 

    $ modinfo <KERNEL_MODULE_NAME>

For example:
$ modinfo virtio_net

filename:       /lib/modules/4.18.0-94.el8.x86_64/kernel/drivers/net/virtio_net.ko.xz
license:        GPL
description:    Virtio network driver
rhelversion:    8.1
srcversion:     2E9345B281A898A91319773
alias:          virtio:d00000001v*
depends:        net_failover
intree:         Y
name:           virtio_net
vermagic:       4.18.0-94.el8.x86_64 SMP mod_unload modversions
…​
parm:           napi_weight:int
parm:           csum:bool
parm:           gso:bool
parm:           napi_tx:bool

    O comando modinfo exibe algumas informações detalhadas sobre o módulo de kernel especificado. Você pode consultar informações sobre todos os módulos disponíveis, independentemente de estarem ou não carregados. As entradas parm mostram parâmetros que o usuário é capaz de definir para o módulo, e que tipo de valor eles esperam.

    Nota

    Ao inserir o nome de um módulo de kernel, não anexe a extensão .ko.xz ao final do nome. Os nomes dos módulos do kernel não têm extensões; seus arquivos correspondentes têm.

Recursos adicionais

  • Para mais informações sobre o modinfo, consulte a página do manual modinfo(8).

3.8. Carregamento de módulos do núcleo em tempo de execução do sistema

A maneira ideal de expandir a funcionalidade do kernel Linux é carregando módulos do kernel. O procedimento seguinte descreve como usar o comando modprobe para encontrar e carregar um módulo do kernel no kernel atualmente em execução.

Pré-requisitos

  • Permissões de raiz
  • O pacote kmod está instalado.
  • O respectivo módulo do núcleo não é carregado. Para garantir que este seja o caso, liste os módulos do kernel carregados.

Procedimento

  1. Selecione um módulo de kernel que você deseja carregar.

    Os módulos estão localizados no diretório /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

  2. Carregar o módulo de núcleo relevante: 

    # modprobe <MODULE_NAME>
    Nota

    Ao inserir o nome de um módulo de kernel, não anexe a extensão .ko.xz ao final do nome. Os nomes dos módulos do kernel não têm extensões; seus arquivos correspondentes têm.

  3. Opcionalmente, verifique se o módulo relevante foi carregado: 

    $ lsmod | grep <MODULE_NAME>

    Se o módulo foi carregado corretamente, este comando exibe o módulo do kernel relevante. Por exemplo: 

    $ lsmod | grep serio_raw
serio_raw              16384  0
Importante

As mudanças descritas neste procedimento will not persist após reiniciar o sistema.

Recursos adicionais

  • Para mais detalhes sobre modprobe, consulte a página do manual modprobe(8).

3.9. Descarga de módulos do núcleo em tempo de execução do sistema

S vezes, você descobre que precisa descarregar certos módulos do kernel em execução. O procedimento seguinte descreve como usar o comando modprobe para encontrar e descarregar um módulo do kernel em tempo de execução do sistema a partir do kernel atualmente carregado.

Pré-requisitos

  • Permissões de raiz
  • O pacote kmod está instalado.

Procedimento

  1. Execute o comando lsmod e selecione um módulo do kernel que você deseja descarregar.

    Se um módulo de kernel tiver dependências, descarregue-as antes de descarregar o módulo de kernel. Para detalhes sobre a identificação de módulos com dependências, veja Seção 3.4, “Listagem dos módulos do kernel atualmente carregados”.

  2. Descarregar o módulo do núcleo relevante: 

    # modprobe -r <MODULE_NAME>

    Ao inserir o nome de um módulo de kernel, não anexe a extensão .ko.xz ao final do nome. Os nomes dos módulos do kernel não têm extensões; seus arquivos correspondentes têm.

    Atenção

    Não descarregue os módulos do núcleo quando eles são utilizados pelo sistema em execução. Isso pode levar a um sistema instável ou não-operacional.

  3. Opcionalmente, verificar se o módulo relevante foi descarregado: 

    $ lsmod | grep <MODULE_NAME>

    Se o módulo foi descarregado com sucesso, este comando não exibe nenhuma saída.

Importante

Após terminar este procedimento, os módulos do kernel que são definidos para serem carregados automaticamente na inicialização, will not stay unloaded após reiniciar o sistema. Para informações sobre como combater este resultado, veja Prevenir que os módulos do kernel sejam carregados automaticamente no momento da inicialização do sistema.

Recursos adicionais

  • Para mais detalhes sobre modprobe, consulte a página do manual modprobe(8).

3.10. Carregamento automático dos módulos do núcleo no momento da inicialização do sistema

O procedimento a seguir descreve como configurar um módulo de kernel para que ele seja carregado automaticamente durante o processo de inicialização.

Pré-requisitos

  • Permissões de raiz
  • O pacote kmod está instalado.

Procedimento

  1. Selecione um módulo de kernel que você deseja carregar durante o processo de inicialização.

    Os módulos estão localizados no diretório /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

  2. Criar um arquivo de configuração para o módulo: 

    # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf
    Nota

    Ao inserir o nome de um módulo de kernel, não anexe a extensão .ko.xz ao final do nome. Os nomes dos módulos do kernel não têm extensões; seus arquivos correspondentes têm.

  3. Opcionalmente, após a reinicialização, verificar se o módulo relevante foi carregado: 

    $ lsmod | grep <MODULE_NAME>

    O comando de exemplo acima deve ser bem sucedido e exibir o módulo de kernel relevante.

Importante

As mudanças descritas neste procedimento will persist após reiniciar o sistema.

Recursos adicionais

  • Para mais detalhes sobre o carregamento de módulos do kernel durante o processo de inicialização, consulte a página do manual modules-load.d(5).

3.11. Impedir que os módulos do núcleo sejam carregados automaticamente no momento da inicialização do sistema

O procedimento seguinte descreve como adicionar um módulo de kernel a um denilista para que ele não seja carregado automaticamente durante o processo de inicialização.

Pré-requisitos

  • Permissões de raiz
  • O pacote kmod está instalado.
  • Certifique-se de que um módulo do núcleo em um denilista não seja vital para a configuração atual de seu sistema.

Procedimento

  1. Selecione um módulo do núcleo que você deseja colocar em um denilista: 

    $ lsmod

Module                  Size  Used by
fuse                  126976  3
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  1
uinput                 20480  1
xt_conntrack           16384  1
…​

    O comando lsmod exibe uma lista de módulos carregados para o kernel atualmente em execução.

    • Alternativamente, identifique um módulo de kernel descarregado que você deseja evitar de carregar potencialmente.

      Todos os módulos do kernel estão localizados no diretório /lib/modules/<KERNEL_VERSION>/kernel/<SUBSYSTEM>/.

  2. Criar um arquivo de configuração para um denilista: 

    # vim /etc/modprobe.d/blacklist.conf

	# Blacklists <KERNEL_MODULE_1>
	blacklist <MODULE_NAME_1>
	install <MODULE_NAME_1> /bin/false

	# Blacklists <KERNEL_MODULE_2>
	blacklist <MODULE_NAME_2>
	install <MODULE_NAME_2> /bin/false

	# Blacklists <KERNEL_MODULE_n>
	blacklist <MODULE_NAME_n>
	install <MODULE_NAME_n> /bin/false
	…​

    O exemplo mostra o conteúdo do arquivo blacklist.conf, editado pelo editor vim. A linha blacklist garante que o módulo do kernel relevante não será carregado automaticamente durante o processo de inicialização. O comando blacklist, entretanto, não impede que o módulo seja carregado como uma dependência para outro módulo do kernel que não esteja em um denylist. Portanto, a linha install faz com que o /bin/false seja executado ao invés de instalar um módulo.

    As linhas que começam com um sinal de hash são comentários para tornar o arquivo mais legível.

    Nota

    Ao inserir o nome de um módulo de kernel, não anexe a extensão .ko.xz ao final do nome. Os nomes dos módulos do kernel não têm extensões; seus arquivos correspondentes têm.

  3. Criar uma cópia de segurança da imagem inicial do ramdisk atual antes de reconstruir: 

    # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date %m-\r%H%M%S).img

    O comando acima cria uma imagem de backup initramfs caso a nova versão tenha um problema inesperado.

    • Alternativamente, crie uma cópia de segurança de outra imagem ramdisk inicial que corresponda à versão do kernel para a qual você deseja colocar os módulos do kernel em um denylist: 

      # cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date %m-\r%H%M%S)

  4. Gerar uma nova imagem ramdisk inicial para refletir as mudanças: 

    # dracut -f -v

    • Se você estiver construindo uma imagem ramdisk inicial para uma versão do kernel diferente da que você está inicializando atualmente, especifique tanto a versão alvo initramfs quanto a versão do kernel: 

      # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

  5. Reinicie o sistema: 

    $ reboot
Importante

As mudanças descritas neste procedimento will take effect and persist após reiniciar o sistema. Se você colocar inadequadamente um módulo chave do núcleo em um denylist, você pode enfrentar um sistema instável ou não operacional.

Recursos adicionais

  • Para mais detalhes sobre a utilidade dracut, consulte a página do manual dracut(8).

3.12. Assinatura de módulos de kernel para inicialização segura

Você pode aumentar a segurança de seu sistema usando módulos de kernel assinados. As seções seguintes descrevem como autoassinar módulos de kernel privados para uso com o RHEL 8 em sistemas de construção baseados em UEFI onde o Secure Boot está habilitado. Estas seções também fornecem uma visão geral das opções disponíveis para importar sua chave pública para um sistema alvo onde você deseja implantar seus módulos do kernel.

Para assinar e carregar módulos do núcleo, você precisa:

  1. Autenticar um módulo de kernel.
  2. Gerar um par de chaves públicas e privadas.
  3. Importar a chave pública no sistema alvo.
  4. Assine o módulo do kernel com a chave privada.
  5. Carregar o módulo de kernel assinado.

Se a inicialização segura for ativada, os carregadores de inicialização do sistema operacional UEFI, o kernel do Red Hat Enterprise Linux e todos os módulos do kernel devem ser assinados com uma chave privada e autenticados com a chave pública correspondente. Se eles não forem assinados e autenticados, o sistema não terá permissão para terminar o processo de inicialização.

A distribuição RHEL 8 inclui:

  • Carregadores de inicialização assinados
  • Caroços assinados
  • Módulos de kernel assinados

Além disso, o carregador de inicialização assinado no primeiro estágio e o kernel assinado incluem chaves públicas da Red Hat embutidas. Estes binários executáveis assinados e chaves incorporadas permitem que a RHEL 8 instale, inicialize e execute com as chaves da Microsoft UEFI Secure Boot Certification Authority que são fornecidas pelo firmware UEFI em sistemas que suportam o UEFI Secure Boot. Note que nem todos os sistemas baseados em UEFI incluem suporte para Inicialização Segura.

Pré-requisitos

Para poder assinar módulos de kernel construídos externamente, instale as utilidades listadas na tabela a seguir no sistema de construção.

Tabela 3.1. Utilidades requeridas

UtilitárioFornecido por pacoteUsado emObjetivo

openssl

openssl

Construir sistema

Gera o par de chaves públicas e privadas X.509

sign-file

kernel-devel

Construir sistema

Arquivo executável utilizado para assinar um módulo de kernel com a chave privada

mokutil

mokutil

Sistema alvo

Utilitário opcional usado para cadastrar manualmente a chave pública

keyctl

keyutils

Sistema alvo

Utilitário opcional usado para exibir chaves públicas no chaveiro do sistema

Nota

O sistema de construção, onde você constrói e assina seu módulo de kernel, não precisa ter o UEFI Secure Boot habilitado e não precisa sequer ser um sistema baseado no UEFI.

3.12.1. Autenticação de módulos de kernel com chaves X.509

No RHEL 8, quando um módulo do kernel é carregado, o kernel verifica a assinatura do módulo contra as chaves públicas X.509 do chaveiro do sistema do kernel (.builtin_trusted_keys) e do chaveiro da plataforma do kernel (.platform). O chaveiro .platform contém chaves de provedores de plataformas de terceiros e chaves públicas personalizadas. As chaves do sistema do kernel .blacklist são excluídas da verificação. As seções seguintes fornecem uma visão geral das fontes de chaves, chaveiros e exemplos de chaves carregadas de diferentes fontes no sistema. Além disso, você pode ver como autenticar um módulo do kernel.

3.12.1.1. Requisitos de autenticação

Você precisa atender a certas condições para carregar módulos do núcleo em sistemas com a funcionalidade UEFI Secure Boot habilitada.

Se o UEFI Secure Boot estiver ativado ou se o parâmetro do kernel module.sig_enforce tiver sido especificado:

  • Você só pode carregar aqueles módulos de kernel assinados cujas assinaturas foram autenticadas contra chaves do chaveiro do sistema (.builtin_trusted_keys) e do chaveiro da plataforma (.platform).
  • A chave pública não deve estar no chaveiro revogado do sistema (.blacklist).

Se o UEFI Secure Boot estiver desativado e o parâmetro do kernel module.sig_enforce não tiver sido especificado:

  • Você pode carregar módulos kernel não assinados e módulos kernel assinados sem uma chave pública.

Se o sistema não for baseado na UEFI ou se a UEFI Secure Boot estiver desativada:

  • Apenas as chaves embutidas no kernel são carregadas em .builtin_trusted_keys e .platform.
  • Você não tem a capacidade de aumentar esse conjunto de chaves sem reconstruir o núcleo.

Tabela 3.2. Requisitos de autenticação do módulo Kernel para carregamento

Módulo assinadoChave pública encontrada e assinatura válidaUEFI Secure Boot statesig_enforceCarga do móduloNúcleo manchado

Não assinado

-

Não habilitado

Não habilitado

Sucesso

Sim

Não habilitado

Habilitado

Falhas

-

Habilitado

-

Falhas

-

Assinado

Não

Não habilitado

Não habilitado

Sucesso

Sim

Não habilitado

Habilitado

Falhas

-

Habilitado

-

Falhas

-

Assinado

Sim

Não habilitado

Não habilitado

Sucesso

Não

Não habilitado

Habilitado

Sucesso

Não

Habilitado

-

Sucesso

Não

3.12.1.2. Fontes para chaves públicas

Durante a inicialização, o núcleo carrega chaves X.509 de um conjunto de armazéns de chaves persistentes para os seguintes chaveiros:

  • O chaveiro do sistema (.builtin_trusted_keys)
  • O chaveiro .platform
  • O sistema .blacklist keyring

Tabela 3.3. Fontes para chaveiros de sistema

Fonte das chaves X.509O usuário pode adicionar chavesUEFI Secure Boot stateChaves carregadas durante a inicialização

Embutido no núcleo

Não

-

.builtin_trusted_keys

Bota Segura UEFI "db

Limitado

Não habilitado

Não

Habilitado

.platform

Embutido no shim.efi boot loader

Não

Não habilitado

Não

Habilitado

.builtin_trusted_keys

Lista de chaves do proprietário da máquina (MOK)

Sim

Não habilitado

Não

Habilitado

.platform

.builtin_trusted_keys:

  • um porta-chaves que é construído sobre o porta-chaves
  • contém chaves públicas confiáveis
  • os privilégios do root são necessários para visualizar as chaves

.platform:

  • um porta-chaves que é construído sobre o porta-chaves
  • contém chaves de fornecedores de plataformas de terceiros e chaves públicas personalizadas
  • os privilégios do root são necessários para visualizar as chaves

.blacklist

  • um chaveiro com chaves X.509 que foram revogadas
  • um módulo assinado por uma chave de .blacklist falhará a autenticação mesmo que sua chave pública esteja em .builtin_trusted_keys

UEFI Secure Boot db:

  • um banco de dados de assinaturas
  • armazena chaves (hashes) de aplicações UEFI, drivers UEFI, e bootloaders
  • as chaves podem ser carregadas na máquina

UEFI Secure Boot dbx:

  • um banco de dados de assinaturas revogado
  • impede que as chaves sejam carregadas
  • as chaves revogadas deste banco de dados são adicionadas ao chaveiro .blacklist

3.12.1.3. Geração de um par de chaves públicas e privadas

Você precisa gerar um par de chaves públicas e privadas X.509 para ter sucesso em seus esforços de usar os módulos do kernel em um sistema habilitado para Boot Seguro. Mais tarde, você usará a chave privada para assinar o módulo do kernel. Você também terá que adicionar a chave pública correspondente à Chave do Proprietário da Máquina (MOK) para o Secure Boot para validar o módulo assinado.

Alguns dos parâmetros para esta geração de pares chave são melhor especificados com um arquivo de configuração.

Procedimento

  1. Criar um arquivo de configuração com parâmetros para a geração do par de chaves: 

    # cat << EOF > configuration_file.config
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts

[ req_distinguished_name ]
O = Organization
CN = Organization signing key
emailAddress = E-mail address

[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid
EOF

  2. Criar um par de chaves públicas e privadas X.509, como mostrado no exemplo a seguir: 

    # openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \
-batch -config configuration_file.config -outform DER \
-out my_signing_key_pub.der \
-keyout my_signing_key.priv

    A chave pública será escrita para o my_signing_key_pub.der e a chave privada será escrita para o arquivo my_signing_key.priv arquivo.

    Importante

    No RHEL 8, as datas de validade do par chave são importantes. A chave não expira, mas o módulo do kernel deve ser assinado dentro do período de validade de sua chave de assinatura. Por exemplo, uma chave válida somente em 2019 pode ser usada para autenticar um módulo do kernel assinado em 2019 com essa chave. Entretanto, os usuários não podem usar essa chave para assinar um módulo de kernel em 2020.

  3. Opcionalmente, você pode rever as datas de validade de suas chaves públicas, como no exemplo abaixo: 

    # openssl x509 -inform der -text -noout -in <my_signing_key_pub.der>

Validity
            Not Before: Feb 14 16:34:37 2019 GMT
            Not After : Feb 11 16:34:37 2029 GMT
  4. Inscreva sua chave pública em todos os sistemas onde você deseja autenticar e carregar seu módulo de kernel.
Atenção

Aplique fortes medidas de segurança e políticas de acesso para proteger o conteúdo de sua chave privada. Nas mãos erradas, a chave poderia ser usada para comprometer qualquer sistema que seja autenticado pela chave pública correspondente.

Recursos adicionais

3.12.2. Exemplo de saída de chaveiros de sistema

Você pode exibir informações sobre as chaves nos chaveiros do sistema usando o utilitário keyctl.

A seguir, um exemplo abreviado de .builtin_trusted_keys, .platform e .blacklist keyrings de um sistema RHEL 8 onde o UEFI Secure Boot está habilitado. 

# keyctl list %:.builtin_trusted_keys
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# keyctl list %:.platform
4 keys in keyring:
...asymmetric: VMware, Inc.: 4ad8da0472073...
...asymmetric: Red Hat Secure Boot CA 5: cc6fafe72...
...asymmetric: Microsoft Windows Production PCA 2011: a929f298e1...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4e0bd82...

# keyctl list %:.blacklist
4 keys in keyring:
...blacklist: bin:f5ff83a...
...blacklist: bin:0dfdbec...
...blacklist: bin:38f1d22...
...blacklist: bin:51f831f...

O chaveiro .builtin_trusted_keys acima mostra a adição de duas chaves do Boot Seguro da UEFI {\i1}"db{\i} assim como o Red Hat Secure Boot (CA key 1), que está embutido no carregador de inicialização shim.efi.

O exemplo a seguir mostra a saída do console do kernel. As mensagens identificam as chaves com uma fonte relacionada ao UEFI Secure Boot. Estas incluem a UEFI Secure Boot db, calço embutido e a lista MOK. 

# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...

Recursos adicionais

  • Para mais informações sobre keyctl veja keyctl(1) página do manual.
  • Para mais informações sobre dmesg veja dmesg(1) página do manual.

3.12.3. Inscrição de chave pública no sistema alvo

Quando a RHEL 8 inicializa em um sistema baseado em UEFI com boot seguro ativado, o kernel carrega no chaveiro do sistema (.builtin_trusted_keys) todas as chaves públicas que estão no banco de dados de chaves Secure Boot db. Ao mesmo tempo, o kernel exclui as chaves do banco de dados dbx de chaves revogadas. As seções abaixo descrevem diferentes maneiras de importar uma chave pública em um sistema alvo para que o chaveiro do sistema (.builtin_trusted_keys) seja capaz de usar a chave pública para autenticar um módulo do kernel.

3.12.3.1. Imagem do firmware de fábrica incluindo chave pública

Para facilitar a autenticação de seu módulo de kernel em seus sistemas, considere solicitar a seu fornecedor de sistemas que incorpore sua chave pública no banco de dados de chaves UEFI Secure Boot em sua imagem de firmware de fábrica.

3.12.3.2. Acrescentar manualmente a chave pública à lista MOK

O recurso de chave do proprietário da máquina (MOK) pode ser usado para expandir o banco de dados de chaves de Boot Seguro da UEFI. Quando a RHEL 8 inicializa um sistema UEFI com boot seguro ativado, as chaves da lista MOK também são adicionadas ao chaveiro do sistema (.builtin_trusted_keys), além das chaves do banco de dados de chaves. As chaves da lista MOK também são armazenadas de forma persistente e segura da mesma forma que as chaves do banco de dados do Secure Boot, mas estas são duas facilidades separadas. A instalação MOK é suportada por shim.efi, MokManager.efi, grubx64.efi, e pelo utilitário mokutil.

A inscrição de uma chave MOK requer a interação manual de um usuário no console do sistema UEFI em cada sistema alvo. Entretanto, a instalação MOK fornece um método conveniente para testar os pares de chaves recém-gerados e testar os módulos do kernel assinados com eles.

Procedimento

  1. Solicite a adição de sua chave pública à lista MOK: 

    # mokutil --import my_signing_key_pub.der

    Você será solicitado a entrar e confirmar uma senha para este pedido de inscrição MOK.

  2. Reinicialize a máquina.

    O pedido de inscrição da chave MOK pendente será notado por shim.efi e será lançado MokManager.efi para permitir que você complete a inscrição a partir do console UEFI.

  3. Digite a senha que você associou anteriormente a esta solicitação e confirme a matrícula.

    Sua chave pública é adicionada à lista MOK, que é persistente.

Assim que uma chave estiver na lista MOK, ela será automaticamente propagada para o chaveiro do sistema neste e nas botas subseqüentes quando a UEFI Secure Boot estiver habilitada.

3.12.4. Assinatura de módulos de kernel com a chave privada

Os usuários podem obter maiores benefícios de segurança em seus sistemas carregando módulos de kernel assinados se o mecanismo UEFI Secure Boot estiver habilitado. As seções seguintes descrevem como assinar módulos de kernel com a chave privada.

Pré-requisitos

Procedimento

  • Executar o utilitário sign-file com parâmetros como mostrado no exemplo abaixo: 

    # /usr/src/kernels/$(uname -r)/scripts/sign-file \ sha256 \ my_signing_key.priv \ my_signing_key_pub.der \ my_module.ko

    sign-file computa e anexa a assinatura diretamente à imagem ELF em seu arquivo de módulo do kernel. O utilitário modinfo pode ser usado para exibir informações sobre a assinatura do módulo do kernel, caso ele esteja presente.

    Nota

    A assinatura anexa não está contida em uma seção de imagem ELF e não é uma parte formal da imagem ELF. Portanto, utilitários como readelf não serão capazes de exibir a assinatura em seu módulo do núcleo.

    Seu módulo de núcleo está agora pronto para ser carregado. Note que seu módulo de kernel assinado também é carregável em sistemas onde o UEFI Secure Boot está desabilitado ou em um sistema não UEFI. Isso significa que você não precisa fornecer tanto uma versão assinada como uma não assinada de seu módulo de kernel.

    Importante

    No RHEL 8, as datas de validade do par chave são importantes. A chave não expira, mas o módulo do kernel deve ser assinado dentro do período de validade de sua chave de assinatura. O utilitário sign-file não o advertirá sobre isso. Por exemplo, uma chave que só é válida em 2019 pode ser usada para autenticar um módulo do kernel assinado em 2019 com essa chave. Entretanto, os usuários não podem usar essa chave para assinar um módulo de kernel em 2020.

Recursos adicionais

3.12.5. Carregamento de módulos de núcleo assinado

Uma vez que sua chave pública esteja inscrita no chaveiro do sistema (.builtin_trusted_keys) e na lista MOK, e após ter assinado o respectivo módulo kernel com sua chave privada, você pode finalmente carregar seu módulo kernel assinado com o comando modprobe, conforme descrito na seção seguinte.

Pré-requisitos

Procedimento

  1. Verifique se suas chaves públicas estão no chaveiro do sistema: 

    # keyctl list %:.builtin_trusted_keys

  2. Copie o módulo do kernel para o diretório /extra/ do kernel que você deseja: 

    # cp my_module.ko /lib/modules/$(uname -r)/extra/

  3. Atualizar a lista de dependência modular: 

    # depmod -a

  4. Carregar o módulo de kernel e verificar se foi carregado com sucesso: 

    # modprobe -v my_module
# lsmod | grep my_module

    1. Opcionalmente, para carregar o módulo na inicialização, adicione-o ao arquivo /etc/modules-loaded.d/my_module.conf: 

      # echo "my_module" > /etc/modules-load.d/my_module.conf

Recursos adicionais

Capítulo 4. Configuração dos parâmetros de linha de comando do kernel

Os parâmetros da linha de comando do kernel são uma forma de alterar o comportamento de certos aspectos do kernel do Red Hat Enterprise Linux no momento da inicialização. Como administrador de sistemas, você tem controle total sobre quais opções são definidas no momento da inicialização. Certos comportamentos do kernel só podem ser definidos no momento da inicialização, portanto, entender como fazer estas mudanças é uma habilidade chave de administração.

Importante

Optar por mudar o comportamento do sistema modificando os parâmetros da linha de comando do kernel pode ter efeitos negativos em seu sistema. Portanto, você deve testar as mudanças antes de implementá-las na produção. Para maiores orientações, entre em contato com o Suporte da Red Hat.

4.1. Entendendo os parâmetros da linha de comando do kernel

Os parâmetros da linha de comando do kernel são usados para a configuração do tempo de inicialização:

  • O núcleo do Red Hat Enterprise Linux
  • O disco RAM inicial
  • As características do espaço do usuário

Os parâmetros de tempo de inicialização do kernel são freqüentemente usados para sobrescrever valores padrão e para definir configurações de hardware específicas.

Por padrão, os parâmetros de linha de comando do kernel para sistemas que utilizam o carregador de inicialização GRUB2 são definidos na variável kernelopts do arquivo /boot/grub2/grubenv para todas as entradas de inicialização do kernel.

Nota

Para IBM Z, os parâmetros da linha de comando do kernel são armazenados no arquivo de configuração de entrada de inicialização porque o carregador de inicialização zipl não suporta variáveis de ambiente. Portanto, a variável de ambiente kernelopts não pode ser usada.

Recursos adicionais

4.2. O que é

grubby é um utilitário para manipulação de arquivos de configuração específicos do bootloader.

Você pode usar grubby também para alterar a entrada padrão do boot, e para adicionar/remover argumentos de uma entrada do menu GRUB2.

Para obter mais detalhes, consulte a página do manual grubby(8).

4.3. O que são entradas de inicialização

Uma entrada de inicialização é uma coleção de opções que são armazenadas em um arquivo de configuração e vinculadas a uma versão particular do kernel. Na prática, você tem pelo menos tantas entradas de inicialização quanto seu sistema tem kernels instalados. O arquivo de configuração da entrada de inicialização está localizado no diretório /boot/loader/entries/ e pode se parecer com este: 

6f9cc9cb7d7845d49698c9537337cedc-4.18.0-5.el8.x86_64.conf

O nome do arquivo acima consiste de uma identificação de máquina armazenada no arquivo /etc/machine-id, e uma versão do kernel.

O arquivo de configuração de entrada de inicialização contém informações sobre a versão do kernel, a imagem ramdisk inicial e a variável de ambiente kernelopts, que contém os parâmetros da linha de comando do kernel. O conteúdo de uma configuração de entrada de inicialização pode ser visto abaixo: 

title Red Hat Enterprise Linux (4.18.0-74.el8.x86_64) 8.0 (Ootpa)
version 4.18.0-74.el8.x86_64
linux /vmlinuz-4.18.0-74.el8.x86_64
initrd /initramfs-4.18.0-74.el8.x86_64.img $tuned_initrd
options $kernelopts $tuned_params
id rhel-20190227183418-4.18.0-74.el8.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

A variável de ambiente kernelopts está definida no arquivo /boot/grub2/grubenv.

Recursos adicionais

Para mais informações sobre a variável kernelopts, veja o artigo da base de conhecimento Como instalar e inicializar kernels personalizados no Red Hat Enterprise Linux 8.

4.4. Ajuste dos parâmetros da linha de comando do kernel

Para ajustar o comportamento de seu sistema desde os estágios iniciais do processo de inicialização, você precisa definir certos parâmetros de linha de comando do kernel.

Esta seção explica como alterar os parâmetros da linha de comando do kernel em várias arquiteturas de CPU.

4.4.1. Mudança dos parâmetros de linha de comando do kernel para todas as entradas de inicialização

Este procedimento descreve como alterar os parâmetros de linha de comando do kernel para todas as entradas de inicialização em seu sistema.

Pré-requisitos

  • Verifique se as utilidades grubby e zipl estão instaladas em seu sistema.

Procedimento

  • Para adicionar um parâmetro: 

    # grubby --update-kernel=ALL --args="<NEW_PARAMETER>"

    Para sistemas que utilizam o bootloader GRUB2, o comando atualiza o arquivo /boot/grub2/grubenv adicionando um novo parâmetro do kernel à variável kernelopts nesse arquivo.

    No IBM Z que usa o bootloader zIPL, o comando adiciona um novo parâmetro de kernel a cada /boot/loader/entries/<ENTRY>.conf arquivo.

    • No IBM Z, execute o comando zipl sem opções de atualização do menu de inicialização.

  • Para remover um parâmetro: 

    # grubby --update-kernel=ALL --remove-args="<PARAMETER_TO_REMOVE>"
    • No IBM Z, execute o comando zipl sem opções de atualização do menu de inicialização.

Recursos adicionais

4.4.2. Alteração dos parâmetros da linha de comando do kernel para uma única entrada de inicialização

Este procedimento descreve como alterar os parâmetros da linha de comando do kernel para uma única entrada de inicialização em seu sistema.

Pré-requisitos

  • Verifique se as utilidades grubby e zipl estão instaladas em seu sistema.

Procedimento

  • Para adicionar um parâmetro: 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"
    • No IBM Z, execute o comando zipl sem opções de atualização do menu de inicialização.

  • Para remover um parâmetro, use o seguinte: 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<PARAMETER_TO_REMOVE>"
    • No IBM Z, execute o comando zipl sem opções de atualização do menu de inicialização.
Nota

Nos sistemas que utilizam o arquivo grub.cfg, existe, por padrão, o parâmetro options para cada entrada de inicialização do kernel, que é definido para a variável kernelopts. Esta variável é definida no arquivo de configuração /boot/grub2/grubenv.

Importante

Nos sistemas GRUB2:

  • Se os parâmetros da linha de comando do kernel forem modificados para todas as entradas de inicialização, o utilitário grubby atualiza a variável kernelopts no arquivo /boot/grub2/grubenv.
  • Se os parâmetros da linha de comando do kernel forem modificados para uma única entrada de inicialização, a variável kernelopts é expandida, os parâmetros do kernel são modificados e o valor resultante é armazenado no arquivo /boot/loader/entries/<RELEVANT_KERNEL_BOOT_ENTRY.conf> da respectiva entrada de inicialização.

Em sistemas zIPL:

  • grubby modifica e armazena os parâmetros da linha de comando do kernel de uma entrada de inicialização individual do kernel no /boot/loader/entries/<ENTRY>.conf arquivo.

Recursos adicionais

Capítulo 5. Configuração dos parâmetros do kernel em tempo de execução

Como administrador de sistemas, você pode modificar muitas facetas do comportamento do kernel do Red Hat Enterprise Linux em tempo de execução. Esta seção descreve como configurar os parâmetros do kernel em tempo de execução, usando o comando sysctl e modificando os arquivos de configuração nos diretórios /etc/sysctl.d/ e /proc/sys/.

5.1. O que são parâmetros do kernel

Os parâmetros do kernel são valores ajustáveis que você pode ajustar enquanto o sistema está em funcionamento. Não há necessidade de reiniciar ou recompilar o kernel para que as mudanças tenham efeito.

É possível abordar os parâmetros do kernel através:

  • O comando sysctl
  • O sistema de arquivo virtual montado no diretório /proc/sys/
  • Os arquivos de configuração no diretório /etc/sysctl.d/

Os túneis são divididos em classes pelo subsistema de kernel. O Red Hat Enterprise Linux tem as seguintes classes sintonizáveis:

Tabela 5.1. Tabela de classes de sysctl

Classe sintonizávelSubsistema

abi

Domínios e personalidades de execução

crypto

Interfaces criptográficas

debug

Interfaces de depuração do kernel

dev

Informações específicas sobre os dispositivos

fs

Sintonizáveis globais e específicos do sistema de arquivo

kernel

Sintonizadores globais de kernel

net

Sintonizadores de rede

sunrpc

Chamada de Procedimento Remoto do Sol (NFS)

usuário

Limites do espaço de nomes de usuários

vm

Afinação e gerenciamento de memória, buffers e cache

Recursos adicionais

  • Para mais informações sobre sysctl, consulte as páginas do manual sysctl(8).
  • Para mais informações sobre /etc/sysctl.d/ veja, sysctl.d(5) páginas do manual.

5.2. Ajuste dos parâmetros do núcleo em tempo de execução

Importante

A configuração dos parâmetros do kernel em um sistema de produção requer um planejamento cuidadoso. Alterações não planejadas podem tornar o kernel instável, exigindo uma reinicialização do sistema. Verifique se você está usando opções válidas antes de alterar quaisquer valores do kernel.

5.2.1. Configuração temporária dos parâmetros do kernel com sysctl

O procedimento a seguir descreve como usar o comando sysctl para definir temporariamente os parâmetros do kernel em tempo de execução. O comando também é útil para listar e filtrar os sintonizadores.

Pré-requisitos

Procedimento

  1. Para listar todos os parâmetros e seus valores, use o seguinte: 

    # sysctl -a
    Nota

    O comando # sysctl -a exibe os parâmetros do kernel, que podem ser ajustados em tempo de execução e em tempo de inicialização.

  2. Para configurar um parâmetro temporariamente, use o comando como no exemplo a seguir: 

    # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

    O comando de amostra acima altera o valor do parâmetro enquanto o sistema está em funcionamento. As mudanças entram em vigor imediatamente, sem necessidade de reiniciar.

    Nota

    As mudanças retornam ao padrão após o reinício de seu sistema.

Recursos adicionais

  • Para mais informações sobre sysctl, consulte a página do manual sysctl(8).
  • Para modificar permanentemente os parâmetros do kernel, use o comandosysctl para escrever os valores no arquivo /etc/sysctl.conf ou faça alterações manuais nos arquivos de configuração no diretório/etc/sysctl.d/ .

5.2.2. Configuração permanente dos parâmetros do kernel com sysctl

O procedimento a seguir descreve como usar o comando sysctl para definir permanentemente os parâmetros do kernel.

Pré-requisitos

Procedimento

  1. Para listar todos os parâmetros, use o seguinte: 

    # sysctl -a

    O comando exibe todos os parâmetros do kernel que podem ser configurados em tempo de execução.

  2. Para configurar um parâmetro permanentemente: 

    # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

    O comando de amostra altera o valor sintonizável e o grava no arquivo /etc/sysctl.conf, que sobrepõe os valores padrão dos parâmetros do kernel. As mudanças entram em vigor imediata e persistentemente, sem necessidade de reinício.

Nota

Para modificar permanentemente os parâmetros do kernel, você também pode fazer alterações manuais nos arquivos de configuração no diretório /etc/sysctl.d/.

Recursos adicionais

5.2.3. Usando arquivos de configuração em /etc/sysctl.d/ para ajustar os parâmetros do kernel

O procedimento seguinte descreve como modificar manualmente os arquivos de configuração no diretório /etc/sysctl.d/ para definir permanentemente os parâmetros do kernel.

Pré-requisitos

Procedimento

  1. Criar um novo arquivo de configuração em /etc/sysctl.d/: 

    # vim /etc/sysctl.d/<some_file.conf>

  2. Incluir parâmetros de kernel, um por linha, como se segue: 

    <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
<TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
  3. Salvar o arquivo de configuração.

  4. Reinicie a máquina para que as mudanças entrem em vigor.

    • Alternativamente, para aplicar as mudanças sem reiniciar, executar: 

      # sysctl -p /etc/sysctl.d/<some_file.conf>

      O comando permite a leitura dos valores do arquivo de configuração, que você criou anteriormente.

Recursos adicionais

  • Para mais informações sobre sysctl, consulte a página do manual sysctl(8).
  • Para mais informações sobre /etc/sysctl.d/, consulte a página do manual sysctl.d(5).

5.2.4. Configuração temporária dos parâmetros do kernel através de /proc/sys/

O procedimento a seguir descreve como definir temporariamente os parâmetros do kernel através dos arquivos no diretório /proc/sys/ do sistema de arquivos virtual.

Pré-requisitos

Procedimento

  1. Identificar um parâmetro do kernel que você deseja configurar: 

    # ls -l /proc/sys/<TUNABLE_CLASS>/

    Os arquivos graváveis retornados pelo comando podem ser usados para configurar o kernel. Os arquivos com permissões somente de leitura fornecem feedback sobre as configurações atuais.

  2. Atribuir um valor-alvo ao parâmetro kernel: 

    # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

    O comando faz mudanças de configuração que desaparecerão assim que o sistema for reiniciado.

  3. Opcionalmente, verifique o valor do parâmetro do kernel recém ajustado: 

    # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

Recursos adicionais

5.3. Manter os parâmetros de pânico do núcleo desabilitados em ambientes virtualizados

Ao configurar um ambiente virtualizado no Red Hat Enterprise Linux 8 (RHEL 8), você não deve ativar os parâmetros do kernel softlockup_panic e nmi_watchdog, pois o ambiente virtualizado pode desencadear um bloqueio suave espúrio que não deve exigir um pânico do sistema.

As seções seguintes explicam as razões por trás deste conselho, resumindo-as:

  • O que causa um bloqueio suave.
  • Descrevendo os parâmetros de kernel que controlam o comportamento de um sistema em um bloqueio suave.
  • Explicando como os bloqueios suaves podem ser acionados em um ambiente virtualizado.

5.3.1. O que é um bloqueio suave?

Um bloqueio suave é uma situação geralmente causada por um bug, quando uma tarefa é executada no espaço do kernel de uma CPU sem reprogramação. A tarefa também não permite que nenhuma outra tarefa seja executada naquela CPU em particular. Como resultado, um aviso é exibido a um usuário através do console do sistema. Este problema também é chamado de disparo de travamento suave.

Recursos adicionais

  • Por uma razão técnica por trás de um bloqueio suave, exemplos de mensagens de registro, e outros detalhes, veja o seguinte Knowledge Article.

5.3.2. Parâmetros que controlam o pânico no núcleo

Os seguintes parâmetros do núcleo podem ser definidos para controlar o comportamento de um sistema quando um bloqueio suave é detectado.

softlockup_panic

Controla se o núcleo entra ou não em pânico quando um bloqueio suave é detectado.

TipoValorEfeito

Inteiro

0

o kernel não entra em pânico com fechadura macia

Inteiro

1

pânico no miolo em um bloqueio macio

Por padrão, na RHEL8 este valor é 0.

A fim de entrar em pânico, o sistema precisa detectar primeiro um bloqueio duro. A detecção é controlada pelo parâmetro nmi_watchdog.

nmi_watchdog

Controla se os mecanismos de detecção de lockup (watchdogs) estão ativos ou não. Este parâmetro é do tipo inteiro.

ValorEfeito

0

desabilita o detector de bloqueio

1

permite o bloqueio do detector

O detector de travamento rígido monitora cada CPU quanto à sua capacidade de responder a interrupções.

watchdog_thresh

Controla a freqüência do cão de guarda hrtimer, eventos NMI, e limiares de bloqueio suave/duro.

Limite por defeitoLimiar de bloqueio suave

10 segundos

2 * watchdog_thresh

A definição deste parâmetro para zero desabilita totalmente a detecção de bloqueio.

Recursos adicionais

5.3.3. Trancamentos suaves e espúrios em ambientes virtualizados

O travamento suave acionado em hosts físicos, como descrito em Seção 5.3.1, “O que é um bloqueio suave?”, geralmente representa um kernel ou bug de hardware. O mesmo fenômeno que ocorre em sistemas operacionais convidados em ambientes virtualizados pode representar um falso aviso.

A carga de trabalho pesada sobre um host ou a alta contenção sobre algum recurso específico, como a memória, geralmente causa um falso disparo de um cadeado macio. Isto porque o anfitrião pode programar a CPU do convidado por um período superior a 20 segundos. Então, quando a CPU do convidado é novamente programada para rodar no host, ela experimenta um time jump que aciona os devidos temporizadores. Os temporizadores incluem também o watchdog hrtimer, que pode conseqüentemente reportar um travamento suave na CPU do convidado.

Como um bloqueio suave em um ambiente virtualizado pode ser espúrio, você não deve ativar os parâmetros do kernel que causariam pânico no sistema quando um bloqueio suave for reportado em uma CPU de convidado.

Importante

Para entender os trancamentos suaves nos hóspedes, é essencial saber que o anfitrião agenda o hóspede como uma tarefa, e o hóspede então agenda suas próprias tarefas.

Recursos adicionais

5.4. Ajuste dos parâmetros do kernel para servidores de banco de dados

Existem diferentes conjuntos de parâmetros de kernel que podem afetar o desempenho de aplicações específicas de bancos de dados. As seções seguintes explicam quais parâmetros do kernel devem ser configurados para garantir o funcionamento eficiente dos servidores de banco de dados e das bases de dados.

5.4.1. Introdução aos servidores de banco de dados

Um servidor de banco de dados é um dispositivo de hardware que tem uma certa quantidade de memória principal, e um aplicativo de banco de dados (DB) instalado. Esta aplicação DB fornece serviços como um meio de escrever os dados em cache da memória principal, que normalmente é pequena e cara, para arquivos DB (banco de dados). Estes serviços são fornecidos a vários clientes em uma rede. Pode haver tantos servidores de banco de dados quanto a memória principal de uma máquina e o armazenamento permitem.

O Red Hat Enterprise Linux 8 fornece as seguintes aplicações de banco de dados:

  • MariaDB 10.3
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6
  • PostgreSQL 12 - disponível desde RHEL 8.1.1

5.4.2. Parâmetros que afetam o desempenho das aplicações de banco de dados

Os seguintes parâmetros do kernel afetam o desempenho das aplicações de banco de dados.

fs.aio-max-nr

Define o número máximo de operações assíncronas de E/S que o sistema pode realizar no servidor.

Nota

O aumento do parâmetro fs.aio-max-nr não produz mudanças adicionais além do aumento do limite do aio.

fs.file-max

Define o número máximo de manipulações de arquivos (nomes de arquivos temporários ou IDs atribuídos a arquivos abertos) que o sistema suporta em qualquer instância.

O kernel aloca dinamicamente as alças dos arquivos sempre que uma alça de arquivo é solicitada por uma aplicação. O kernel, no entanto, não libera esses manipuladores de arquivos quando eles são liberados pela aplicação. Em vez disso, o kernel recicla estes manipuladores de arquivos. Isto significa que, com o tempo, o número total de file handles alocados aumentará mesmo que o número de file handles usados atualmente possa ser baixo.

kernel.shmall
Define o número total de páginas de memória compartilhada que podem ser usadas em todo o sistema. Para utilizar toda a memória principal, o valor do parâmetro kernel.shmall deve ser ≤ tamanho total da memória principal.
kernel.shmmax
Define o tamanho máximo em bytes de um único segmento de memória compartilhada que um processo Linux pode alocar em seu espaço de endereçamento virtual.
kernel.shmmni
Define o número máximo de segmentos de memória compartilhada que o servidor de banco de dados é capaz de lidar.
net.ipv4.ip_local_port_range
Define a faixa de porta que o sistema pode usar para programas que desejam se conectar a um servidor de banco de dados sem um número de porta específico.
net.core.rmem_default
Define a memória padrão do soquete de recepção através do Protocolo de Controle de Transmissão (TCP).
net.core.rmem_max
Define a memória máxima do soquete de recepção através do Protocolo de Controle de Transmissão (TCP).
net.core.wmem_default
Define a memória padrão do soquete de envio através do Protocolo de Controle de Transmissão (TCP).
net.core.wmem_max
Define a memória máxima do soquete de envio através do Protocolo de Controle de Transmissão (TCP).
vm.dirty_bytes / vm.dirty_ratio
Define um limite em bytes / em porcentagem de memória suja na qual um processo gerando dados sujos é iniciado na função write().
Nota

Either vm.dirty_bytes or vm.dirty_ratio pode ser especificado de cada vez.

vm.dirty_background_bytes / vm.dirty_background_ratio
Define um limite em bytes / em porcentagem de memória suja em que o kernel tenta escrever ativamente dados sujos no disco rígido.
Nota

Either vm.dirty_background_bytes or vm.dirty_background_ratio pode ser especificado de cada vez.

vm.dirty_writeback_centisecs

Define um intervalo de tempo entre os despertares periódicos dos fios do núcleo responsáveis pela escrita de dados sujos no disco rígido.

Estes parâmetros de kernel medem em 100º de um segundo.

vm.dirty_expire_centisecs

Define o tempo após o qual os dados sujos são suficientemente velhos para serem escritos em disco rígido.

Estes parâmetros de kernel medem em 100º de um segundo.

Recursos adicionais

Capítulo 6. Começando com o registro do kernel

Arquivos de log são arquivos que contêm mensagens sobre o sistema, incluindo o kernel, serviços e aplicações em execução no mesmo. O sistema de registro no Red Hat Enterprise Linux é baseado no protocolo syslog embutido. Vários utilitários usam este sistema para registrar eventos e organizá-los em arquivos de log. Estes arquivos são úteis ao auditar o sistema operacional ou solucionar problemas.

6.1. O que é o tampão de anel de amêndoa

Durante o processo de inicialização, o console fornece muitas informações importantes sobre a fase inicial da inicialização do sistema. Para evitar a perda das mensagens iniciais, o kernel utiliza o que é chamado de buffer de anel. Este buffer armazena todas as mensagens, inclusive as mensagens de inicialização, geradas pela função printk() dentro do código do kernel. As mensagens do buffer de anéis do kernel são então lidas e armazenadas em arquivos de log em armazenamento permanente, por exemplo, pelo serviço syslog.

O buffer mencionado acima é uma estrutura de dados cíclica que tem um tamanho fixo, e é codificada no núcleo. Os usuários podem exibir os dados armazenados no buffer de anel do kernel através do comando dmesg ou do arquivo /var/log/boot.log. Quando o buffer de anéis está cheio, os novos dados sobrescrevem os antigos.

Recursos adicionais

  • Para mais informações sobre syslog, consulte a página do manual syslog(2).
  • Para mais detalhes sobre como examinar ou controlar as mensagens de registro de inicialização com dmesg, consulte a página do manual dmesg(1).

6.2. Papel da impressão em nível de log e kernel logging

Cada mensagem que o kernel reporta tem um nível de log associado a ela que define a importância da mensagem. O buffer de anel do kernel, conforme descrito em Seção 6.1, “O que é o tampão de anel de amêndoa”, coleta mensagens do kernel de todos os níveis de log. É o parâmetro kernel.printk que define quais mensagens do buffer são impressas para o console.

Os valores em nível de log se decompõem nesta ordem:

  • 0 - Emergência do núcleo. O sistema é inutilizável.
  • 1 - Alerta de kernel. As ações devem ser tomadas imediatamente.
  • 2 - A condição do miolo é considerada crítica.
  • 3 - Condição de erro geral do kernel.
  • 4 - Condição geral de alerta do núcleo.
  • 5 - Aviso de uma condição normal, mas significativa.
  • 6 - Mensagem informativa do kernel.
  • 7 - Mensagens de nível de depuração do kernel.

Por padrão, kernel.printk no RHEL 8 contém os quatro valores a seguir: 

# sysctl kernel.printk
kernel.printk = 7	4	1	7

Os quatro valores definem o seguinte:

  1. valor. O nível de log do console, define a prioridade mais baixa de mensagens impressas no console.
  2. valor. Nível de registro padrão para mensagens sem um nível de registro explícito anexado a elas.
  3. valor. Define a configuração mais baixa possível do nível de log para o nível de log do console.

  4. valor. Define o valor padrão para o nível de log do console no momento da inicialização.

    Cada um desses valores acima define uma regra diferente para o tratamento de mensagens de erro.

Importante

O valor padrão 7 4 1 7 printk permite uma melhor depuração da atividade do kernel. Entretanto, quando acoplado a um console serial, esta configuração printk é capaz de causar explosões intensas de E/S que podem levar a um sistema RHEL a ficar temporariamente sem resposta. Para evitar estas situações, a configuração de um valor printk de 4 4 1 7 normalmente funciona, mas às custas de perder a informação extra de depuração.

Observe também que certos parâmetros de linha de comando do kernel, tais como quiet ou debug, alteram os valores padrão kernel.printk.

Recursos adicionais

  • Para mais informações sobre kernel.printk e níveis de log, consulte a página do manual syslog(2).

Capítulo 7. Instalando e configurando o kdump

7.1. O que é kdump

kdump é um serviço que fornece um mecanismo de despejo de emergência. O serviço permite salvar o conteúdo da memória do sistema para análise posterior. kdump usa a chamada do sistema kexec para inicializar no segundo kernel (a capture kernel) sem reinicializar; e então captura o conteúdo da memória do kernel travado (a crash dump ou a vmcore) e o salva. O segundo kernel reside em uma parte reservada da memória do sistema.

Importante

Um despejo de kernel pode ser a única informação disponível no caso de uma falha no sistema (um bug crítico). Portanto, garantir que kdump esteja operacional é importante em ambientes de missão crítica. A Red Hat recomenda que os administradores de sistema atualizem e testem regularmente kexec-tools em seu ciclo normal de atualização do kernel. Isto é especialmente importante quando novos recursos do kernel são implementados.

7.2. Instalando o kdump

Em muitos casos, o serviço kdump é instalado e ativado por default nas novas instalações do Red Hat Enterprise Linux. O Anaconda o instalador fornece uma tela para a configuração kdump ao realizar uma instalação interativa usando a interface gráfica ou de texto. A tela do instalador tem o título Kdump e está disponível na tela principal Installation Summary, e permite apenas uma configuração limitada - você só pode selecionar se kdump está habilitado e quanta memória está reservada.

Enable kdump during RHEL installation

Algumas opções de instalação, tais como instalações Kickstart personalizadas, em alguns casos não instalam ou ativam kdump por padrão. Se este for o caso em seu sistema, siga o procedimento abaixo para instalar kdump.

Pré-requisitos

  • Uma assinatura ativa do Red Hat Enterprise Linux
  • Um repositório contendo o kexec-tools pacote para a arquitetura da CPU de seu sistema
  • Cumpridos os requisitos kdump

Procedimento

  1. Execute o seguinte comando para verificar se kdump está instalado em seu sistema: 

    $ rpm -q kexec-tools

    Saída se o pacote for instalado: 

    kexec-tools-2.0.17-11.el8.x86_64

    Saída se o pacote não estiver instalado: 

    package kexec-tools is not installed

  2. Instale kdump e outros pacotes necessários por: 

    # yum install kexec-tools
Importante

Começando com o Red Hat Enterprise Linux 7.4 (kernel-3.10.0-693.el7), o driver Intel IOMMU é suportado com kdump. Para versões anteriores, Red Hat Enterprise Linux 7.3 (kernel-3.10.0-514[.XYZ].el7) e anteriores, é aconselhável que o suporte Intel IOMMU seja desativado, caso contrário o kdump kernel provavelmente não responderá.

Recursos adicionais

7.3. Configuração do kdump na linha de comando

7.3.1. Configuração do uso da memória kdump

A memória para kdump é reservada durante a inicialização do sistema. O tamanho da memória é configurado no arquivo de configuração do Grand Unified Bootloader (GRUB) 2 do sistema. O tamanho da memória depende do valor crashkernel= especificado no arquivo de configuração e do tamanho da memória física do sistema.

A opção crashkernel= pode ser definida de várias maneiras. Você pode especificar o valor crashkernel= ou configurar a opção auto. A opção crashkernel=auto boot, reserva a memória automaticamente, dependendo da quantidade total de memória física do sistema. Quando configurado, o kernel reservará automaticamente uma quantidade apropriada de memória necessária para o kernel kdump. Isto ajuda a evitar a ocorrência de erros fora da memória (OOM).

Nota

A alocação automática de memória para kdump varia de acordo com a arquitetura de hardware do sistema e o tamanho da memória disponível.

Por exemplo, no AMD64 e Intel 64, o parâmetro crashkernel=auto só funciona quando a memória disponível é superior a 1GB e a arquitetura ARM de 64 bits e os sistemas IBM Power Systems têm memória disponível superior a 2GB.

Se o sistema tiver menos do que o limite mínimo de memória para alocação automática, você pode configurar manualmente a quantidade de memória reservada.

Pré-requisitos

Procedimento

  1. Edite o arquivo /etc/default/grub usando as permissões de raiz.

  2. Defina a opção crashkernel= para o valor requerido.

    Por exemplo, para reservar 128 MB de memória, use o seguinte: 

    crashkernel=128M

    Alternativamente, você pode definir a quantidade de memória reservada para uma variável, dependendo da quantidade total de memória instalada. A sintaxe da reserva de memória em uma variável é crashkernel=<range1>:<size1>,<range2>:<size2>. Por exemplo: 

    crashkernel=512M-2G:64M,2G-:128M

    O exemplo acima reserva 64 MB de memória se a quantidade total de memória do sistema for 512 MB ou superior e inferior a 2 GB. Se a quantidade total de memória for superior a 2 GB, 128 MB são reservados para kdump.

    • Deslocar a memória reservada.

      Alguns sistemas exigem reservar memória com um certo deslocamento fixo, uma vez que a reserva de crashkernel é muito cedo, e quer reservar alguma área para uso especial. Se o offset for definido, a memória reservada começa lá. Para compensar a memória reservada, use a seguinte sintaxe: 

      crashkernel=128M@16M

      O exemplo acima significa que kdump reserva 128 MB de memória a partir de 16 MB (endereço físico 0x01000000). Se o parâmetro de desvio for ajustado para 0 ou omitido completamente, kdump compensa automaticamente a memória reservada. Esta sintaxe também pode ser usada ao definir uma reserva de memória variável como descrito acima; neste caso, o offset é sempre especificado por último (por exemplo, crashkernel=512M-2G:64M,2G-:128M@16M).

  3. Use o seguinte comando para atualizar o arquivo de configuração do GRUB2: 

    # grub2-mkconfig -o /boot/grub2/grub.cfg
Nota

A forma alternativa de configurar a memória para kdump é anexar o crashkernel=<SOME_VALUE> para a variável kernelopts com o grub2-editenv que atualizará todas as suas entradas de inicialização. Ou você pode usar o utilitário grubby para atualizar os parâmetros de linha de comando do kernel de apenas uma entrada.

Recursos adicionais

7.3.2. Configurando o alvo kdump

Quando uma falha no núcleo é capturada, o núcleo pode ser armazenado como um arquivo em um sistema de arquivo local, escrito diretamente em um dispositivo, ou enviado através de uma rede usando o protocolo NFS (Network File System) ou SSH (Secure Shell). Apenas uma destas opções pode ser definida de cada vez, e o comportamento padrão é armazenar o arquivo vmcore no diretório /var/crash/ do sistema de arquivos local.

Pré-requisitos

Procedimento

Para armazenar o arquivo vmcore no diretório /var/crash/ do sistema de arquivos local:

  • Edite o arquivo /etc/kdump.conf e especifique o caminho: 

    caminho /var/crash

    A opção path /var/crash representa o caminho para o sistema de arquivo no qual kdump salva o arquivo vmcore. Quando você especifica um alvo de despejo no arquivo /etc/kdump.conf, então o path é relativo ao alvo de despejo especificado.

    Se você não especificar um alvo de despejo no arquivo /etc/kdump.conf, então o path representa o caminho absoluto a partir do diretório raiz. Dependendo do que está montado no sistema atual, o alvo de despejo e o caminho de despejo ajustado são tomados automaticamente.

Atenção

kdump salva o arquivo vmcore no diretório /var/crash/var/crash, quando o alvo do despejo é montado em /var/crash e a opção path também é definida como /var/crash no arquivo /etc/kdump.conf. Por exemplo, no exemplo a seguir, o sistema de arquivo ext4 já está montado em /var/crash e o path está configurado como /var/crash: 

grep -v ^# etc/kdump.conf | grep -v ^$
ext4 /dev/mapper/vg00-varcrashvol
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31

Isto resulta no caminho /var/crash/var/crash. Para resolver este problema, use a opção path / ao invés de path /var/crash

Para alterar o diretório local no qual o despejo principal deve ser salvo, como root, edite o arquivo de configuração /etc/kdump.conf como descrito abaixo.

  1. Remova o sinal de hash (#) do início da linha #path /var/crash.

  2. Substituir o valor pelo caminho de diretório pretendido. Por exemplo: 

    caminho /usr/local/cores
    Importante

    No Red Hat Enterprise Linux 8, o diretório definido como alvo do kdump usando a diretiva path deve existir quando o serviço systemd kdump for iniciado - caso contrário, o serviço falha. Este comportamento é diferente de versões anteriores do Red Hat Enterprise Linux, onde o diretório estava sendo criado automaticamente se ele não existisse ao iniciar o serviço.

Para escrever o arquivo em uma partição diferente, como root, edite o arquivo de configuração /etc/kdump.conf como descrito abaixo.

  1. Remova o sinal de hash (#) do início da linha #ext4, dependendo de sua escolha.

    • nome do dispositivo (a linha #ext4 /dev/vg/lv_kdump )
    • etiqueta do sistema de arquivo (a linha #ext4 LABEL=/boot )
    • UUID (a linha #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 )

  2. Alterar o tipo de sistema de arquivo, bem como o nome do dispositivo, etiqueta ou UUID para os valores desejados. Por exemplo: 

    ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
    Importante

    Recomenda-se especificar os dispositivos de armazenamento usando um LABEL= ou UUID=. Nomes de dispositivos de disco como /dev/sda3 não são garantidos para ser consistentes durante a reinicialização.

    Importante

    Ao despejar para o Dispositivo de Armazenamento de Acesso Direto (DASD) no hardware IBM Z, é essencial que os dispositivos de despejo sejam especificados corretamente em /etc/dasd.conf antes de prosseguir.

Para escrever o depósito de lixo diretamente em um dispositivo:

  1. Remova o sinal de hash (#) do início da linha #raw /dev/vg/lv_kdump.

  2. Substituir o valor pelo nome do dispositivo pretendido. Por exemplo: 

    bruto /dev/sdb1

Para armazenar a lixeira em uma máquina remota usando o protocolo NFS:

  1. Remova o sinal de hash (#) do início da linha #nfs my.server.com:/export/tmp.

  2. Substituir o valor por um hostname válido e um caminho de diretório. Por exemplo: 

    nfs penguin.example.com:/export/cores

Para armazenar a lixeira em uma máquina remota usando o protocolo SSH:

  1. Remova o sinal de hash (#) desde o início do #ssh user@my.server.com linha.
  2. Substituir o valor por um nome de usuário e um nome de host válidos.

  3. Inclua sua chave SSH na configuração.

    • Remova o sinal de hash do início da linha #sshkey /root/.ssh/kdump_id_rsa.

    • Mude o valor para a localização de uma chave válida no servidor para o qual você está tentando despejar. Por exemplo: 

      ssh john@penguin.example.com
sshkey /root/.ssh/mykey

Recursos adicionais

7.3.3. Configurando o coletor central

O serviço kdump usa um programa core_collector para capturar a imagem vmcore. Na RHEL, o utilitário makedumpfile é o coletor central padrão.

makedumpfile é um programa de despejo que ajuda a comprimir o tamanho de um arquivo de despejo e copiar somente as páginas necessárias usando vários níveis de despejo.

makedumpfile faz um pequeno arquivo de despejo, seja comprimindo os dados do despejo ou excluindo páginas desnecessárias ou ambas. Ele precisa das primeiras informações de depuração do kernel para entender como o primeiro kernel usa a memória. Isto ajuda a detectar as páginas necessárias.

Sintaxe

core_collector makedumpfile -l --message- nível 1 -d 31

Opções

  • -c, -l ou -p: especifique o formato de arquivo comprimido dump por cada página usando a opção zlib para -c, lzo para -l ou snappy para -p.
  • -d (dump_level) : exclui as páginas para que não sejam copiadas para o arquivo dump.
  • --message-level: especifique os tipos de mensagem. Você pode restringir as saídas impressas especificando message_level com esta opção. Por exemplo, especificando 7 como message_level imprime mensagens comuns e mensagens de erro. O valor máximo de message_level é 31

Pré-requisitos

Procedimento

  1. Como root, edite o arquivo de configuração /etc/kdump.conf e remova o sinal de hash (#) do início do #core_collector makedumpfile -l --message-level 1 -d 31.
  2. Para permitir a compressão de arquivos de despejo, execute: 
core_collector makedumpfile -l --message- nível 1 -d 31

onde,

  • -l especifica o formato de arquivo comprimido dump.
  • -d especifica o nível de despejo como 31.
  • --message-level especifica o nível de mensagem como 1.

Além disso, considere os seguintes exemplos utilizando as opções -c e -p:

  • Para comprimir o arquivo de despejo usando -c: 
core_collector makedumpfile -c -d 31 --message-level 1
  • Para comprimir o arquivo de despejo usando -p: 
core_collector makedumpfile -p -d 31 --message-level 1

Recursos adicionais

  • Consulte a página de manual makedumpfile(8) para uma lista completa das opções disponíveis.

7.3.4. Configuração das respostas de falha padrão do kdump

Por padrão, quando kdump falha em criar um arquivo vmcore no local de destino especificado em Seção 7.3.2, “Configurando o alvo kdump”, o sistema é reinicializado, e o dump é perdido no processo. Para mudar este comportamento, siga o procedimento abaixo.

Pré-requisitos

Procedimento

  1. Como root, remova o sinal de hash (#) do início da linha #failure_action no arquivo de configuração /etc/kdump.conf.

  2. Substituir o valor por uma ação desejada, conforme descrito em Seção 7.5.5, “Respostas a falhas padrão suportadas”. Por exemplo: 

    failure_action poweroff

7.3.5. Habilitação e desativação do serviço kdump

Para iniciar o serviço kdump no momento da inicialização, siga o procedimento abaixo.

Pré-requisitos

Procedimento

  1. Para habilitar o serviço kdump, use o seguinte comando: 

    # systemctl enable kdump.service

    Isto permite o serviço para multi-user.target.

  2. Para iniciar o serviço na sessão atual, use o seguinte comando: 

    # systemctl start kdump.service

  3. Para interromper o serviço kdump, digite o seguinte comando: 

    # systemctl stop kdump.service

  4. Para desativar o serviço kdump, execute o seguinte comando: 

    # systemctl disable kdump.service
Atenção

É recomendável definir kptr_restrict=1 como padrão. Quando kptr_restrict é configurado para (1) como padrão, o serviço kdumpctl carrega o kernel de falha mesmo que o Kernel Address Space Layout (KASLR) esteja ativado ou não ativado.

Etapa de solução de problemas

Quando kptr_restrict não está configurado para (1), e se KASLR estiver ativado, o conteúdo do arquivo /proc/kore é gerado como todos os zeros. Conseqüentemente, o serviço kdumpctl não consegue acessar o /proc/kcore e carregar o kernel do crash.

Para contornar este problema, o arquivo kexec-kdump-howto.txt exibe uma mensagem de aviso, que especifica para manter a configuração recomendada como kptr_restrict=1.

Para garantir que o serviço kdumpctl carregue o núcleo do acidente, verifique isso:

  • Kernel kptr_restrict=1 no arquivo sysctl.conf.

Recursos adicionais

7.4. Configuração do kdump no console web

Configurar e testar a configuração kdump no console web RHEL 8.

O console web é parte de uma instalação default do Red Hat Enterprise Linux 8 e habilita ou desabilita o serviço kdump no momento da inicialização. Além disso, o console web permite configurar convenientemente a memória reservada para kdump; ou selecionar o local de salvamento vmcore em um formato não comprimido ou comprimido.

Pré-requisitos

7.4.1. Configuração do uso da memória kdump e localização do alvo no console web

O procedimento abaixo mostra como usar a aba Kernel Dump na interface do console web do Red Hat Enterprise Linux para configurar a quantidade de memória que é reservada para o kdump kernel. O procedimento também descreve como especificar a localização alvo do arquivo vmcore dump e como testar sua configuração.

Pré-requisitos

Procedimento

  1. Abra a aba Kernel Dump e inicie o serviço kdump.
  2. Configure o uso da memória kdump através do command line.

  3. Clique no link ao lado da opção Crash dump location.

    web console initial screen

  4. Selecione a opção Local Filesystem no menu suspenso e especifique o diretório no qual você deseja salvar o despejo.

    web console crashdump target

    • Alternativamente, selecione a opção Remote over SSH no menu suspenso para enviar o vmcore para uma máquina remota usando o protocolo SSH.

      Preencha os campos Server, ssh key, e Directory com o endereço da máquina remota, localização da chave ssh e um diretório de destino.

    • Outra opção é selecionar a opção Remote over NFS no menu suspenso e preencher o campo Mount para enviar o vmcore para uma máquina remota usando o protocolo NFS.

      Nota

      Marque a caixa de seleção Compression para reduzir o tamanho do arquivo vmcore.

  5. Teste sua configuração quebrando o kernel.

    web console test kdump config
    Atenção

    Esta etapa interrompe a execução do núcleo e resulta em um colapso do sistema e perda de dados.

Recursos adicionais

7.5. Configurações e metas kdump suportadas

7.5.1. Requisitos de memória para kdump

Para que kdump possa capturar um kernel crash dump e salvá-lo para análise posterior, uma parte da memória do sistema tem que ser permanentemente reservada para o kernel de captura. Quando reservada, esta parte da memória do sistema não está disponível para o kernel principal.

Os requisitos de memória variam com base em certos parâmetros do sistema. Um dos principais fatores é a arquitetura de hardware do sistema. Para descobrir a arquitetura exata da máquina (como Intel 64 e AMD64, também conhecida como x86_64) e imprimi-la na saída padrão, use o seguinte comando: 

$ uname -m

A tabela abaixo contém uma lista de requisitos mínimos de memória para reservar automaticamente um tamanho de memória para kdump. O tamanho muda de acordo com a arquitetura do sistema e a memória física total disponível.

Tabela 7.1. Quantidade mínima de memória reservada necessária para a kdump

ArquiteturaMemória disponívelMemória mínima reservada

AMD64 e Intel 64 (x86_64)

1 GB a 4 GB

160 MB de RAM.

4 GB a 64 GB

192 MB de RAM.

64 GB a 1 TB

256 MB de RAM.

1 TB e mais

512 MB de RAM.

Arquitetura ARM de 64 bits (arm64)

2 GB e mais

448 MB de RAM.

IBM Power Systems (ppc64le)

2 GB a 4 GB

384 MB de RAM.

4 GB a 16 GB

512 MB de RAM.

16 GB a 64 GB

1 GB de RAM.

64 GB a 128 GB

2 GB de RAM.

128 GB e mais

4 GB de RAM.

IBM Z (s390x)

1 GB a 4 GB

160 MB de RAM.

4 GB a 64 GB

192 MB de RAM.

64 GB a 1 TB

256 MB de RAM.

1 TB e mais

512 MB de RAM.

Em muitos sistemas, kdump é capaz de estimar a quantidade de memória necessária e reservá-la automaticamente. Este comportamento é ativado por padrão, mas só funciona em sistemas que possuem mais do que uma certa quantidade de memória total disponível, que varia de acordo com a arquitetura do sistema.

Importante

A configuração automática da memória reservada com base na quantidade total de memória no sistema é uma estimativa de melhor esforço. A memória realmente necessária pode variar devido a outros fatores, tais como dispositivos de E/S. O uso insuficiente de memória pode fazer com que um kernel debug não seja capaz de iniciar como um kernel de captura em caso de pânico do kernel. Para evitar este problema, aumente suficientemente a memória do kernel em caso de pânico.

Recursos adicionais

7.5.2. Limiar mínimo para reserva automática de memória

Em alguns sistemas, é possível alocar a memória para kdump automaticamente, seja usando o parâmetro crashkernel=auto no arquivo de configuração do carregador de inicialização, ou habilitando esta opção no utilitário de configuração gráfica. Para que esta reserva automática funcione, entretanto, é necessário que uma certa quantidade de memória total esteja disponível no sistema. A quantidade difere de acordo com a arquitetura do sistema.

A tabela abaixo lista os limites para alocação automática de memória. Se o sistema tiver menos memória do que a especificada na tabela, a memória precisa ser reservada manualmente.

Tabela 7.2. Quantidade mínima de memória necessária para a reserva automática de memória

ArquiteturaMemória Requerida

AMD64 e Intel 64 (x86_64)

2 GB

IBM Power Systems (ppc64le)

2 GB

IBM Z (s390x)

4 GB

Recursos adicionais

7.5.3. Alvos kdump apoiados

Quando uma falha no kernel é capturada, o arquivo vmcore dump pode ser escrito diretamente em um dispositivo, armazenado como um arquivo em um sistema de arquivo local, ou enviado através de uma rede. A tabela abaixo contém uma lista completa de alvos de despejo que são atualmente suportados ou explicitamente não suportados por kdump.

Tabela 7.3. Alvos kdump apoiados

TipoAlvos suportadosAlvos não suportados

Dispositivo bruto

Todos os discos e divisórias em bruto fixados localmente.

 

Sistema de arquivo local

ext2, ext3, ext4, e xfs sistemas de arquivo em unidades de disco diretamente anexadas, drives lógicos RAID de hardware, dispositivos LVM, e matrizes mdraid.

Qualquer sistema de arquivo local não explicitamente listado como suportado nesta tabela, incluindo o tipo auto (detecção automática de sistema de arquivo).

Diretório remoto

Diretórios remotos acessados usando o protocolo NFS ou SSH sobre IPv4.

Diretórios remotos no sistema de arquivos rootfs acessados usando o protocolo NFS.

Diretórios remotos acessados usando o protocolo iSCSI sobre os iniciadores de hardware e software.

Diretórios remotos acessados usando o protocolo iSCSI em be2iscsi hardware.

Armazéns com vários caminhos.

 

Diretórios remotos acessados através de IPv6.

 

Diretórios remotos acessados usando o protocolo SMB ou CIFS.

 

Diretórios remotos acessados usando o protocolo FCoE (Fibre Channel over Ethernet).

 

Diretórios remotos acessados usando interfaces de rede sem fio.

Importante

A utilização de dump assistido por firmware (fadump) para capturar um vmcore e armazená-lo em uma máquina remota usando SSH ou protocolo NFS causa a renomeação da interface de rede para kdump-<interface-name>. A renomeação acontece se o <interface-name> for genérico, por exemplo *eth#, net#, e assim por diante. Este problema ocorre porque os scripts de captura do vmcore no disco RAM inicial (initrd) adicionam o prefixo kdump- ao nome da interface de rede para garantir a atribuição de nomes persistentes. Como o mesmo initrd é usado também para uma inicialização regular, o nome da interface é alterado também para o kernel de produção.

Recursos adicionais

7.5.4. Níveis de filtragem kdump suportados

Para reduzir o tamanho do arquivo de despejo, kdump usa o coletor central makedumpfile para comprimir os dados e opcionalmente para omitir informações indesejadas. A tabela abaixo contém uma lista completa dos níveis de filtragem que são atualmente suportados pelo utilitário makedumpfile.

Tabela 7.4. Níveis de Filtragem Suportados

OpçãoDescrição

1

Zero páginas

2

Páginas de cache

4

Cache privado

8

Páginas do usuário

16

Páginas livres

Nota

O comando makedumpfile suporta a remoção de páginas enormes transparentes e páginas hugetlbfs. Considere estes dois tipos de páginas de hugetlbfs e remova-as usando o nível -8.

Recursos adicionais

7.5.5. Respostas a falhas padrão suportadas

Por padrão, quando kdump falha em criar uma lixeira de núcleo, o sistema operacional é reinicializado. Você pode, no entanto, configurar kdump para realizar uma operação diferente caso não consiga salvar o despejo do núcleo para o alvo principal. A tabela abaixo lista todas as ações padrão que são atualmente suportadas.

Tabela 7.5. Ações padrão suportadas

OpçãoDescrição

dump_to_rootfs

Tentativa de salvar o despejo do núcleo para o sistema de arquivo raiz. Esta opção é especialmente útil em combinação com um alvo de rede: se o alvo de rede for inalcançável, esta opção configura o kdump para salvar o core dump localmente. O sistema é reinicializado em seguida.

reboot

Reiniciar o sistema, perdendo o núcleo de despejo no processo.

halt

Pare o sistema, perdendo o despejo do núcleo no processo.

poweroff

Desligue o sistema, perdendo o despejo do núcleo no processo.

shell

Executar uma sessão shell de dentro do initramfs, permitindo que o usuário registre o despejo do núcleo manualmente.

Recursos adicionais

7.5.6. Estimativa do tamanho do kdump

Ao planejar e construir seu ambiente kdump, é necessário saber quanto espaço é necessário para o arquivo dump antes de ser produzido.

O comando makedumpfile --mem-usage fornece um relatório útil sobre páginas excluíveis, e pode ser usado para determinar qual nível de despejo você quer atribuir. Execute este comando quando o sistema estiver sob carga representativa, caso contrário makedumpfile --mem-usage retorna um valor menor do que o esperado em seu ambiente de produção. 

[root@hostname ~]# makedumpfile --mem-usage /proc/kcore

TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
----------------------------------------------------------------------
ZERO            501635                  yes             Pages filled with zero
CACHE           51657                   yes             Cache pages
CACHE_PRIVATE   5442                    yes             Cache pages + private
USER            16301                   yes             User process pages
FREE            77738211                yes             Free pages
KERN_DATA       1333192                 no              Dumpable kernel data
Importante

O comando makedumpfile --mem-usage informa em pages. Isto significa que você tem que calcular o tamanho da memória em uso em relação ao tamanho da página do kernel. Por default o kernel do Red Hat Enterprise Linux usa 4 páginas de tamanho KB para arquiteturas AMD64 e Intel 64, e 64 páginas de tamanho KB para arquiteturas IBM POWER.

7.6. Teste da configuração do kdump

O procedimento a seguir descreve como testar se o processo de despejo do grão funciona e é válido antes que a máquina entre em produção.

Atenção

Os comandos abaixo provocam o colapso do kernel. Tenha cuidado ao seguir estes passos e nunca os use descuidadamente no sistema de produção ativo.

Procedimento

  1. Reinicie o sistema com kdump habilitado.

  2. Certifique-se de que kdump esteja funcionando: 

    ~]# systemctl is-active kdump
active

  3. Forçar o kernel do Linux a cair: 

    echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
    Atenção

    O comando acima quebra o núcleo e uma reinicialização é necessária.

    Uma vez iniciados novamente, os address-YYYY-MM-DD-HH:MM:SS/vmcore é criado no local que você especificou em /etc/kdump.conf (por padrão para /var/crash/).

    Nota

    Além de confirmar a validade da configuração, é possível usar esta ação para registrar quanto tempo leva para que um despejo de queda seja concluído, enquanto uma carga representativa estava em funcionamento.

7.7. Usando o kexec para reiniciar o kernel

A chamada de sistema kexec permite carregar e inicializar em outro kernel a partir do kernel atualmente em execução, executando assim uma função de um carregador de inicialização de dentro do kernel.

O utilitário kexec carrega o kernel e a imagem initramfs para a chamada do sistema kexec para inicializar em outro kernel.

O procedimento a seguir descreve como invocar manualmente a chamada do sistema kexec ao usar o utilitário kexec para reinicializar em outro kernel.

Procedimento

  1. Execute o utilitário kexec: 

    # kexec -l /boot/vmlinuz-3.10.0-1040.el7.x86_64 --initrd=/boot/initramfs-3.10.0-1040.el7.x86_64.img --reuse-cmdline

    O comando carrega manualmente o kernel e a imagem initramfs para a chamada ao sistema kexec.

  2. Reinicie o sistema: 

    # reboot

    O comando detecta o kernel, desliga todos os serviços e então chama o sistema kexec para reiniciar no kernel que você forneceu na etapa anterior.

Atenção

Quando você usa o comando kexec -e para reiniciar o kernel, o sistema não passa pela seqüência padrão de desligamento antes de iniciar o próximo kernel, o que pode causar perda de dados ou um sistema não responsivo.

7.8. Lista negra de drivers de kernel para kdump

A lista negra de drivers de kernel para kdump é um mecanismo para evitar que os drivers de kernel pretendidos sejam carregados. Colocar em lista negra os drivers do kernel previne o oom killer ou outras falhas no kernel.

Para colocar os drivers do kernel na lista negra, você pode atualizar a variável KDUMP_COMMANDLINE_APPEND= no arquivo /etc/sysconfig/kdump e especificar uma das seguintes opções de lista negra:

  • rd.driver.blacklist=<modules>
  • modprobe.blacklist=<modules>

Quando você coloca os drivers da lista negra no arquivo /etc/sysconfig/kdump, impede que o kdump initramfs carregue os módulos da lista negra.

O procedimento a seguir descreve como colocar um driver de kernel na lista negra para evitar falhas no kernel de falha.

Procedimento

  1. Selecione o módulo do núcleo que você pretende colocar na lista negra: 

    $ lsmod

Module                  Size  Used by
fuse                  126976  3
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  1
uinput                 20480  1
xt_conntrack           16384  1

    O comando lsmod exibe uma lista de módulos que são carregados para o kernel em execução no momento.

  2. Atualize a linha KDUMP_COMMANDLINE_APPEND= no arquivo /etc/sysconfig/kdump da seguinte forma: 

    KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

  3. Você também pode atualizar a linha KDUMP_COMMANDLINE_APPEND= no arquivo /etc/sysconfig/kdump da seguinte forma: 

    KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

  4. Reinicie o serviço kdump: 

    $ systemctl restart kdump

Recursos adicionais

  • Para maiores informações sobre o oom killer, veja o seguinte Artigo de Conhecimento.
  • A página de manual dracut.cmdline para opções de lista negra de módulos.

7.9. Executando kdump em sistemas com disco criptografado

Ao executar uma partição criptografada criada pela ferramenta Logical Volume Manager (LVM), os sistemas requerem uma certa quantidade de memória disponível. Se o sistema tiver menos do que a quantidade necessária de memória disponível, o utilitário cryptsetup falha na montagem da partição. Como resultado, a captura do arquivo vmcore em um local de destino kdump local (com LVM e criptografia habilitada), falha no segundo kernel (capturar kernel).

Este procedimento descreve o mecanismo kdump em funcionamento aumentando o valor crashkernel=, usando um alvo remoto kdump, ou usando uma função de derivação chave (KDF).

Procedimento

Execute o mecanismo kdump usando um dos seguintes procedimentos:

  • Para executar o kdump, defina uma das seguintes opções:

    • Configurar um alvo remoto kdump.
    • Definir a lixeira para uma divisória não criptografada.
    • Especifique um valor aumentado em crashkernel= até o nível exigido.

  • Adicione um slot de chave extra usando uma função de derivação de chave (KDF):

    1. cryptsetup luksAddKey --pbkdf pbkdf2 /dev/vda2
    2. cryptsetup config --key-slot 1 --priority prefer /dev/vda2
    3. cryptsetup luksDump /dev/vda2

A utilização do KDF padrão da partição criptografada pode consumir muita memória. Você deve fornecer manualmente a senha no segundo kernel (captura), mesmo que você encontre uma mensagem de erro Out of Memory (OOM).

Atenção

Adicionar um slot de chave extra pode ter um efeito negativo na segurança, já que múltiplas chaves podem descriptografar um volume criptografado. Isto pode causar um risco potencial para o volume.

7.10. Mecanismos de despejo assistido por firmwares

Firmware assisted dump (fadump) é um mecanismo de captura de dump, fornecido como uma alternativa ao mecanismo kdump nos sistemas IBM POWER. Os mecanismos kexec e kdump são úteis para a captura de lixões centrais nos sistemas AMD64 e Intel 64. Entretanto, alguns hardwares como mini sistemas e computadores mainframe, aproveitam o firmware onboard para isolar regiões da memória e evitar qualquer sobregravação acidental de dados que seja importante para a análise de falhas. Esta seção cobre os mecanismos fadump e como eles se integram com o RHEL. O utilitário fadump é otimizado para estes recursos expandidos de dumping nos sistemas IBM POWER.

7.10.1. Descarte assistido por firmware em hardware IBM PowerPC

O utilitário fadump captura o arquivo vmcore de um sistema totalmente reinicializado com PCI e dispositivos de E/S. Este mecanismo usa firmware para preservar regiões de memória durante uma falha e depois reutiliza os scripts de espaço do usuário kdump para salvar o arquivo vmcore. As regiões de memória consistem de todo o conteúdo da memória do sistema, exceto a memória de inicialização, os registros do sistema e as entradas da tabela de páginas de hardware (PTEs).

O mecanismo fadump oferece maior confiabilidade sobre o tipo tradicional de despejo, reiniciando a partição e usando um novo kernel para despejar os dados da falha do kernel anterior. O fadump requer uma plataforma de hardware baseada no processador IBM POWER6 ou uma versão posterior.

Para mais detalhes sobre o mecanismo fadump, incluindo os métodos específicos de reinicialização de hardware PowerPC, consulte o arquivo /usr/share/doc/kexec-tools/fadump-howto.txt.

Nota

A área de memória que não é preservada, conhecida como memória de inicialização, é a quantidade de RAM necessária para iniciar com sucesso o kernel após um evento de falha. Por padrão, o tamanho da memória boot é de 256MB ou 5% do total da RAM do sistema, o que for maior.

Ao contrário do evento kexec-initiated, o mecanismo fadump utiliza o núcleo de produção para recuperar um despejo de queda. Ao arrancar após uma falha, o hardware PowerPC torna o nó de dispositivo /proc/device-tree/rtas/ibm.kernel-dump disponível para o sistema de arquivos proc (procfs). Os scripts fadump-aware kdump, verifique os scripts armazenados vmcore, e então complete o reinício do sistema de forma limpa.

7.10.2. Habilitando o mecanismo de despejo assistido por firmware

A capacidade de despejo de falhas dos sistemas IBM POWER pode ser melhorada ao permitir o mecanismo de despejo assistido por firmware (fadump).

Procedimento

  1. Instalar e configurar kdump conforme descrito no Capítulo 7, "Instalação e configuração do kdump".

  2. Adicione fadump=on à linha GRUB_CMDLINE_LINUX no arquivo /etc/default/grub: 

    GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto
rd.lvm.lv=rhel/root rhgb quiet fadump=on"

  3. (Opcional) Se você quiser especificar a memória de inicialização reservada em vez de usar as configurações padrão, configure crashkernel=xxM para GRUB_CMDLINE_LINUX em /etc/default/grub, onde xx é a quantidade de memória necessária em megabytes: 

    GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=xxM rd.lvm.lv=rhel/root rhgb quiet fadump=on"
    Importante

    A Red Hat recomenda testar todas as opções de configuração de inicialização antes de executá-las. Se você observar erros de Out of Memory (OOM) ao inicializar a partir do kernel do crash, aumente o valor especificado no argumento crashkernel= até que o kernel do crash possa inicializar de forma limpa. Algumas tentativas e erros podem ser necessários neste caso.

7.10.3. Mecanismos de despejo assistidos por firmware em hardware IBM Z

Os sistemas IBM Z suportam os seguintes mecanismos de despejo assistidos por firmware:

  • Stand-alone dump (sadump)
  • VMDUMP

A infra-estrutura kdump é suportada e utilizada nos sistemas IBM Z. Para configurar kdump da RHEL, veja, Capítulo 7, "Installing and configuring kdump" (Instalando e configurando o kdump).

Entretanto, o uso de um dos métodos de despejo assistido por firmware (fadump) para IBM Z pode proporcionar vários benefícios:

  • O mecanismo sadump é iniciado e controlado a partir do console do sistema, e é armazenado em um dispositivo de inicialização IPL.
  • O mecanismo VMDUMP é similar ao sadump. Esta ferramenta também é iniciada a partir do console do sistema, mas recupera o despejo resultante do hardware e o copia para o sistema para análise.
  • Estes métodos (de forma semelhante a outros mecanismos de despejo baseados em hardware) têm a capacidade de capturar o estado de uma máquina na fase inicial de inicialização, antes do início do serviço kdump.
  • Embora VMDUMP contenha um mecanismo para receber o arquivo dump em um sistema Red Hat Enterprise Linux, a configuração e controle de VMDUMP é gerenciada a partir do console de Hardware IBM Z.

A IBM discute sadump em detalhes no artigo Stand-alone dump program e VMDUMP no artigo Creating dumps on z/VM com VMDUMP.

A IBM também tem um conjunto de documentação para usar as ferramentas de despejo no Red Hat Enterprise Linux 7 no artigo Using the Dump Tools on Red Hat Enterprise Linux 7.4.

7.10.4. Usando sadump nos sistemas Fujitsu PRIMEQUEST

O mecanismo da Fujitsu sadump foi projetado para fornecer uma captura de lixo fallback em um evento quando kdump não puder ser concluído com sucesso. O mecanismo sadump é invocado manualmente a partir da interface do Conselho de Administração do sistema (MMB). Usando o MMB, configure kdump como para um servidor Intel 64 ou AMD 64 e então execute os seguintes passos adicionais para habilitar sadump.

Procedimento

  1. Adicione ou edite as seguintes linhas no arquivo /etc/sysctl.conf para garantir que kdump comece como esperado para sadump: 

    kernel.panic=0
kernel.unknown_nmi_panic=1
    Atenção

    Em particular, garantir que após kdump, o sistema não seja reinicializado. Se o sistema for reinicializado após kdump não conseguir salvar o arquivo vmcore, então não é possível invocar o sadump.

  2. Definir o parâmetro failure_action em /etc/kdump.conf apropriadamente como halt ou shell. 

    shell de ação_de_sucesso

Recursos adicionais

Para detalhes sobre como configurar seu hardware para sadump, consulte o Manual de Instalação do Servidor FUJITSU PRIMEQUEST 2000 Series.

7.11. Análise de uma lixeira de núcleo

Para determinar a causa da falha do sistema, você pode usar o crash que fornece um prompt interativo muito semelhante ao GNU Debugger (GDB). Este utilitário permite que você analise interativamente um dump core criado por kdump, netdump, diskdump ou xendump, bem como um sistema Linux em execução. Alternativamente, você tem a opção de usar o Kdump Helper ou Kernel Oops Analyzer.

7.11.1. Instalando o utilitário crash

O seguinte procedimento descreve como instalar o crash ferramenta de análise.

Procedimento

  1. Habilitar os repositórios relevantes: 

    # subscription-manager repos --enable baseos repository
    # subscription-manager repos --enable appstream repository
    # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

  2. Instale o pacote crash: 

    # yum install crash

  3. Instale o pacote kernel-debuginfo: 

    # yum install kernel-debuginfo

    O pacote corresponde ao seu kernel em execução e fornece os dados necessários para a análise do despejo.

Recursos adicionais

7.11.2. Executando e saindo do serviço de emergência

O procedimento a seguir descreve como iniciar o utilitário de ativação do sistema para analisar a causa da falha do sistema.

Pré-requisitos

  • Identificar o kernel atualmente em funcionamento (por exemplo, 4.18.0-5.el8.x86_64).

Procedimento

  1. Para iniciar a utilidade crash, dois parâmetros necessários precisam ser passados para o comando:

    • O debug-info (uma imagem vmlinuz descomprimida), por exemplo /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux fornecido através de um pacote específico kernel-debuginfo.

    • O arquivo vmcore real, por exemplo /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

      O comando crash resultante é então parecido com este: 

      # crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

      Use a mesma versão <kernel> que foi capturada por kdump.

      Exemplo 7.1. Executando o utilitário crash

      O exemplo a seguir mostra a análise de um despejo de núcleo criado em 6 de outubro de 2018 às 14h05, utilizando o núcleo 4.18.0-5.el8.x86_64. 

      ...
WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values

      KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Sat Oct  6 14:05:16 2018
      UPTIME: 01:03:57
LOAD AVERAGE: 0.00, 0.00, 0.00
       TASKS: 586
    NODENAME: localhost.localdomain
     RELEASE: 4.18.0-5.el8.x86_64
     VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
     MACHINE: x86_64  (2904 Mhz)
      MEMORY: 2.9 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 10635
     COMMAND: "bash"
        TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash>

  2. Para sair do prompt interativo e terminar crash, digite exit ou q.

    Exemplo 7.2. Sair do serviço de emergência

    crash> exit
~]#
Nota

O comando crash também pode ser usado como uma ferramenta poderosa para depuração de um sistema ao vivo. No entanto, use-o com cautela para não quebrar seu sistema.

7.11.3. Exibição de vários indicadores no utilitário de crash

Os procedimentos a seguir descrevem como usar o utilitário de falha e exibir vários indicadores, tais como um buffer de mensagens do kernel, um backtrace, um status do processo, informações de memória virtual e arquivos abertos.

Exibição do buffer de mensagens
  • Para exibir o buffer de mensagens do kernel, digite o comando log no prompt interativo, como exibido no exemplo abaixo: 
crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

Digite help log para obter mais informações sobre o uso do comando.

Nota

O buffer de mensagens do kernel inclui as informações mais essenciais sobre a falha do sistema e, como tal, é sempre despejado primeiro no arquivo vmcore-dmesg.txt. Isto é útil quando uma tentativa de obter o arquivo vmcore completo falhou, por exemplo, devido à falta de espaço na localização do alvo. Por padrão, vmcore-dmesg.txt está localizado no diretório /var/crash/.

Exibindo um retrocesso
  • Para exibir o rastreamento da pilha de kernel, use o comando bt. 
crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

Tipo bt <pid> para exibir o backtrace de um processo ou tipo específico help bt para maiores informações sobre o uso de bt.

Exibindo o status de um processo
  • Para exibir o status dos processos no sistema, use o comando ps. 
crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

Use ps <pid> para exibir o status de um único processo específico. Use help ps para mais informações sobre o uso de ps.

Exibição de informações de memória virtual
  • Para exibir informações básicas de memória virtual, digite o comando vm no prompt interativo. 
crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

Use vm <pid> para exibir informações sobre um único processo específico, ou use help vm para obter mais informações sobre o uso de vm.

Exibição de arquivos abertos
  • Para exibir informações sobre arquivos abertos, use o comando files. 
crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

Use files <pid> para exibir arquivos abertos por apenas um processo selecionado, ou use help files para maiores informações sobre o uso de files.

7.11.4. Usando o Kernel Oops Analyzer

O Kernel Oops Analyzer é uma ferramenta que analisa o despejo do crash dump comparando as mensagens oops com questões conhecidas na base de conhecimento.

Pré-requisitos

  • Proteja uma mensagem oops para alimentar o Kernel Oops Analyzer, seguindo as instruções em Red Hat Labs.

Procedimento

  1. Siga o Kernel Oops Analyzer link para acessar a ferramenta.

  2. Navegue pela mensagem oops apertando o botão Browse.

    Kernel oops analyzer
  3. Clique no botão DETECT para comparar a mensagem oops baseada em informações do makedumpfile com soluções conhecidas.

7.12. Usando o kdump precoce para capturar o tempo de boot crashes

Como administrador do sistema, você pode utilizar o suporte early kdump do serviço kdump para capturar um arquivo vmcore do kernel em colapso durante as primeiras etapas do processo de inicialização. Esta seção descreve o que é early kdump, como configurá-lo, e como verificar o status deste mecanismo.

7.12.1. O que é kdump precoce

As falhas no kernel durante a fase de inicialização ocorrem quando o serviço kdump ainda não foi iniciado, e não podem facilitar a captura e o salvamento do conteúdo da memória do kernel que sofreu falhas. Portanto, as informações vitais para a solução de problemas são perdidas.

Para resolver este problema, a RHEL 8 introduziu o recurso early kdump como parte do serviço kdump.

Recursos adicionais

7.12.2. Possibilitando o kdump precoce

Esta seção descreve como habilitar o recurso early kdump para eliminar o risco de perda de informações sobre as quedas prematuras do núcleo do boot.

Pré-requisitos

  • Uma assinatura ativa do Red Hat Enterprise Linux
  • Um repositório contendo o pacote kexec-tools para a arquitetura da CPU de seu sistema
  • Cumpridos os requisitos kdump

Procedimento

  1. Verifique se o serviço kdump está habilitado e ativo: 

    # systemctl is-enabled kdump.service && systemctl is-active kdump.service enabled active

    Se kdump não estiver habilitado e funcionando ver, Seção 7.3.5, “Habilitação e desativação do serviço kdump”.

  2. Reconstruir a imagem initramfs do núcleo de inicialização com a funcionalidade early kdump: 

    dracut -f --add earlykdump

  3. Adicione o parâmetro de linha de comando do kernel rd.earlykdump: 

    grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

  4. Reinicializar o sistema para refletir as mudanças 

    reboot

  5. Opcionalmente, verifique se rd.earlykdump foi adicionado com sucesso e se early kdump foi ativado: 

    # cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-187.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet rd.earlykdump

# journalctl -x | grep early-kdump
Mar 20 15:44:41 redhat dracut-cmdline[304]: early-kdump is enabled.
Mar 20 15:44:42 redhat dracut-cmdline[304]: kexec: loaded early-kdump kernel

Recursos adicionais

Capítulo 8. Aplicação de remendos com kernel live patch

Você pode usar a solução de correção ao vivo do kernel do Red Hat Enterprise Linux para corrigir um kernel em execução sem reinicializar ou reiniciar qualquer processo.

Com esta solução, os administradores do sistema:

  • Pode aplicar imediatamente patches de segurança críticos ao núcleo.
  • Não é necessário esperar por tarefas de longa duração para completar, para que os usuários façam log off, ou por tempo de inatividade programado.
  • Controle mais o tempo de funcionamento do sistema e não sacrifique a segurança ou a estabilidade.

Note que nem todo CVE crítico ou importante será resolvido usando a solução de remendo ao vivo do kernel. Nosso objetivo é reduzir as reinicializações necessárias para os patches relacionados à segurança, e não eliminá-los completamente. Para mais detalhes sobre o escopo da solução de remendos ao vivo, veja o Customer Portal Solutions article.

Atenção

Existem algumas incompatibilidades entre o kernel live patching e outros subcomponentes do kernel. Leia atentamente o site Seção 8.1, “Limitações do kpatch” antes de usar o kernel live patching.

8.1. Limitações do kpatch

  • O recurso kpatch não é um mecanismo de atualização do kernel para fins gerais. Ele é usado para aplicar atualizações simples de segurança e correção de erros quando o reinício do sistema não é imediatamente possível.
  • Não utilize as ferramentas SystemTap ou kprobe durante ou após o carregamento de um patch. O patch pode não ter efeito até que tais sondas tenham sido removidas.

8.2. Apoio para remendos de terceiros ao vivo

O utilitário kpatch é o único utilitário de correção ao vivo do kernel suportado pela Red Hat com os módulos RPM fornecidos pelos repositórios da Red Hat. A Red Hat não suportará quaisquer patches ao vivo que não tenham sido fornecidos pela própria Red Hat.

Se você precisar de apoio para um problema que surja com um remendo vivo de terceiros, a Red Hat recomenda que você abra um caso com o fornecedor do remendo vivo no início de qualquer investigação na qual seja necessária uma determinação da causa raiz. Isto permite que o código fonte seja fornecido se o fornecedor permitir, e que sua organização de suporte forneça assistência na determinação da causa raiz antes de aumentar a investigação para o Suporte da Red Hat.

Para qualquer sistema rodando com patches ao vivo de terceiros, a Red Hat se reserva o direito de solicitar a reprodução com o software fornecido e suportado pela Red Hat. Caso isto não seja possível, exigimos que um sistema similar e uma carga de trabalho sejam implantados em seu ambiente de teste sem aplicação de patches ao vivo, para confirmar se o mesmo comportamento é observado.

Para mais informações sobre políticas de suporte de software de terceiros, veja Como os Serviços de Suporte Global da Red Hat lidam com software, drivers e/ou hardware/hipervisores não certificados ou sistemas operacionais convidados de terceiros?

8.3. Acesso aos trechos vivos do kernel

A capacidade de remendo ao vivo do kernel é implementada como um módulo do kernel (kmod) que é entregue como um pacote RPM.

Todos os clientes têm acesso a patches de kernel live, que são entregues pelos canais habituais. Entretanto, os clientes que não subscreverem uma oferta de suporte estendida perderão o acesso a novos patches para o lançamento menor atual, uma vez que o próximo lançamento menor se torne disponível. Por exemplo, os clientes com assinaturas padrão só serão capazes de ativar o kernel RHEL 8.2 até que o kernel RHEL 8.3 seja lançado.

8.4. Componentes do kernel live patching

Os componentes do kernel live patching são os seguintes:

Módulo de remendo de kernel

  • O mecanismo de entrega para os remendos de kernel live.
  • Um módulo do núcleo que é construído especificamente para o núcleo que está sendo remendado.
  • O módulo de correção contém o código das correções desejadas para o kernel.
  • Os módulos de correção registram-se no subsistema do kernel livepatch e fornecem informações sobre as funções originais a serem substituídas, com as indicações correspondentes para as funções de substituição. Os módulos de correção do kernel são entregues como RPMs.
  • A convenção de nomenclatura é kpatch_<kernel version>_<kpatch version>_<kpatch release>. A parte "kernel version" do nome tem dots e dashes substituído por underscores.
A utilidade kpatch
Um utilitário de linha de comando para gerenciar módulos de patch.
O serviço kpatch
Um serviço systemd exigido por multiuser.target. Este alvo carrega o módulo de patch do kernel no momento da inicialização.

8.5. Como funciona a remenda ao vivo do kernel

A solução de correção do kernel kpatch usa o subsistema livepatch para redirecionar funções antigas para novas funções. Quando um patch de kernel vivo é aplicado a um sistema, as seguintes coisas acontecem:

  1. O módulo de correção do kernel é copiado para o diretório /var/lib/kpatch/ e registrado para reaplicação ao kernel por systemd na próxima inicialização.
  2. O módulo kpatch é carregado no kernel em execução e as novas funções são registradas no mecanismo ftrace com um ponteiro para a localização em memória do novo código.
  3. Quando o kernel acessa a função remendada, ele é redirecionado pelo mecanismo ftrace que contorna as funções originais e redireciona o kernel para a versão remendada da função.

Figura 8.1. Como funciona a remenda ao vivo do kernel

rhel kpatch overview

8.6. Permitindo a correção ao vivo do núcleo

Um módulo de correção do kernel é entregue em um pacote RPM, específico para a versão do kernel que está sendo corrigido. Cada pacote de RPM será atualizado cumulativamente ao longo do tempo.

As seções seguintes descrevem como garantir que você receba todas as futuras atualizações cumulativas de remendos ao vivo para um determinado kernel.

Atenção

A Red Hat não suporta nenhum patche ao vivo de terceiros aplicado a um sistema suportado pela Red Hat.

8.6.1. Assinatura ao vivo do fluxo de remendos

Este procedimento descreve a instalação de um determinado pacote de remendos ao vivo. Ao fazer isso, você se inscreve no fluxo de correções ao vivo para um determinado kernel e assegura que você receba todas as futuras atualizações cumulativas de correções ao vivo para esse kernel.

Atenção

Como os remendos ao vivo são cumulativos, não é possível selecionar quais remendos individuais são implantados para um determinado grão.

Pré-requisitos

  • Permissões de raiz

Procedimento

  1. Opcionalmente, verifique sua versão do kernel: 

    # uname -r
4.18.0-94.el8.x86_64

  2. Procure um pacote de remendos ao vivo que corresponda à versão de seu kernel: 

    # yum search $(uname -r)

  3. Instalar o pacote de remendos ao vivo: 

    # yum install "kpatch-patch = $(uname -r)"

    O comando acima instala e aplica os últimos patches cumulativos ao vivo somente para aquele kernel específico.

    O pacote de remendos ao vivo contém um módulo de remendos, se a versão do pacote for 1-1 ou superior. Nesse caso, o kernel será automaticamente corrigido durante a instalação do pacote de correção ao vivo.

    O módulo de patch do kernel também é instalado no diretório /var/lib/kpatch/ para ser carregado pelo gerente de sistema e serviços systemd durante as futuras reinicializações.

    Nota

    Se ainda não houver nenhum remendo vivo disponível para o kernel dado, um pacote de remendo vivo vazio será instalado. Um pacote de remendos ao vivo vazio terá um pacote kpatch_version-kpatch_release de 0-0, por exemplo kpatch-patch-4_18_0-94-0-0.el8.x86_64.rpm. A instalação do RPM vazio assina o sistema para todos os futuros live patches para o kernel dado.

  4. Opcionalmente, verificar se o miolo está remendado: 

    # kpatch list
Loaded patch modules:
kpatch_4_18_0_94_1_1 [enabled]

Installed patch modules:
kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
…​

    A saída mostra que o módulo de correção do kernel foi carregado no kernel, que agora está corrigido com as últimas correções do pacote kpatch-patch-4_18_0-94-1-1.el8.x86_64.rpm.

Recursos adicionais

  • Para mais informações sobre o utilitário de linha de comando kpatch, consulte a página do manual kpatch(1).
  • Consultar as seções relevantes do Configuring basic system settings para maiores informações sobre a instalação de pacotes de software no Red Hat Enterprise Linux 8.

8.7. Atualização dos módulos de correção do kernel

Como os módulos de correção do kernel são entregues e aplicados através de pacotes RPM, atualizar um módulo de correção do kernel cumulativo é como atualizar qualquer outro pacote RPM.

Pré-requisitos

Procedimento

  • Atualização para uma nova versão cumulativa para o kernel atual: 

    # yum update "kpatch-patch = $(uname -r)"

    O comando acima instala automaticamente e aplica quaisquer atualizações que estejam disponíveis para o kernel atualmente em execução. Incluindo quaisquer correções ao vivo cumulativas lançadas no futuro.

  • Alternativamente, atualizar todos os módulos de patch do kernel instalados: 

    # yum update "kpatch-patch\i1}"
Nota

Quando o sistema é reinicializado no mesmo kernel, o kernel é automaticamente remendado ao vivo novamente pelo serviço kpatch.service systemd.

Recursos adicionais

  • Para maiores informações sobre atualização de pacotes de software, veja as seções relevantes de Configuring basic system settings no Red Hat Enterprise Linux 8.

8.8. Desabilitando a remenda ao vivo do kernel

Caso os administradores de sistemas encontrem alguns efeitos negativos imprevistos relacionados com a solução de correção ao vivo do núcleo do Red Hat Enterprise Linux, eles têm a opção de desativar o mecanismo. As seções seguintes descrevem as maneiras de desativar a solução de remendos ao vivo.

Importante

Atualmente, a Red Hat não suporta a reversão de patches ao vivo sem reiniciar seu sistema. Em caso de qualquer problema, entre em contato com nossa equipe de suporte.

8.8.1. Remoção do pacote de remendos ao vivo

O procedimento a seguir descreve como desativar a solução de correção ao vivo do kernel do Red Hat Enterprise Linux, removendo o pacote de correção ao vivo.

Pré-requisitos

  • Permissões de raiz
  • O pacote de remendos ao vivo é instalado.

Procedimento

  1. Selecione o pacote de remendos ao vivo: 

    # yum list installed | grep kpatch-patch
kpatch-patch-4_18_0-94.x86_64        1-1.el8        @@commandline
…​

    O exemplo de saída acima lista os pacotes de remendos ao vivo que você instalou.

  2. Remover o pacote de remendos vivos: 

    # yum remove kpatch-patch-4_18_0-94.x86_64

    Quando um pacote de remendo vivo é removido, o kernel permanece remendado até a próxima reinicialização, mas o módulo de remendo do kernel é removido do disco. Após a próxima reinicialização, o kernel correspondente não será mais remendado.

  3. Reinicialize seu sistema.

  4. Verificar se o pacote de remendos ao vivo foi removido: 

    # yum list installed | grep kpatch-patch

    O comando não exibe nenhuma saída se o pacote tiver sido removido com sucesso.

  5. Opcionalmente, verifique se a solução de remendo ao vivo do kernel está desativada: 

    # kpatch list
Loaded patch modules:

    O exemplo de saída mostra que o kernel não está remendado e a solução de remendo ao vivo não está ativa porque não há módulos de remendo que estão atualmente carregados.

Recursos adicionais

  • Para mais informações sobre o utilitário de linha de comando kpatch, consulte a página do manual kpatch(1).
  • Para mais informações sobre como remover pacotes de software no RHEL 8, consulte as seções relevantes do Configuring basic system settings.

8.8.2. Desinstalando o módulo de patch do kernel

O procedimento a seguir descreve como evitar que a solução de correção ao vivo do kernel do Red Hat Enterprise Linux aplique um módulo de correção do kernel em boots subsequentes.

Pré-requisitos

  • Permissões de raiz
  • Um pacote de remendos ao vivo é instalado.
  • Um módulo de patch de kernel é instalado e carregado.

Procedimento

  1. Selecione um módulo de correção de kernel: 

    # kpatch list
Loaded patch modules:
kpatch_4_18_0_94_1_1 [enabled]

Installed patch modules:
kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
…​

  2. Desinstale o módulo de patch do kernel selecionado: 

    # kpatch uninstall kpatch_4_18_0_94_1_1
uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

    • Observe que o módulo de patch do kernel desinstalado ainda está carregado: 

      # kpatch list
Loaded patch modules:
kpatch_4_18_0_94_1_1 [enabled]

Installed patch modules:
<NO_RESULT>

      Quando o módulo selecionado é desinstalado, o kernel permanece remendado até a próxima reinicialização, mas o módulo de remendo do kernel é removido do disco.

  3. Reinicialize seu sistema.

  4. Opcionalmente, verifique se o módulo de correção do kernel foi desinstalado: 

    # kpatch list
Loaded patch modules:
…​

    O exemplo de saída acima não mostra nenhum módulo de correção de kernel carregado ou instalado, portanto, o kernel não é corrigido e a solução de correção ao vivo do kernel não está ativa.

Recursos adicionais

  • Para mais informações sobre o utilitário de linha de comando kpatch, consulte a página do manual kpatch(1).

8.8.3. Desabilitando o kpatch.service

O procedimento a seguir descreve como evitar que a solução de correção ao vivo do kernel do Red Hat Enterprise Linux aplique todos os módulos de correção do kernel globalmente em boots subsequentes.

Pré-requisitos

  • Permissões de raiz
  • Um pacote de remendos ao vivo é instalado.
  • Um módulo de patch de kernel é instalado e carregado.

Procedimento

  1. Verifique se kpatch.service está habilitado: 

    # systemctl is-enabled kpatch.service
enabled

  2. Desativar kpatch.service: 

    # systemctl disable kpatch.service
Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

    • Observe que o módulo de patch de kernel aplicado ainda está carregado: 

      # kpatch list
Loaded patch modules:
kpatch_4_18_0_94_1_1 [enabled]

Installed patch modules:
kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
  3. Reinicialize seu sistema.

  4. Opcionalmente, verifique o status de kpatch.service: 

    # systemctl status kpatch.service
● kpatch.service - "Apply kpatch kernel patches"
   Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

    O exemplo de saída atesta que kpatch.service foi desativado e não está funcionando. Por isso, a solução de remendo ao vivo do kernel não está ativa.

  5. Verificar se o módulo de remendo do kernel foi descarregado: 

    # kpatch list
Loaded patch modules:
<NO_RESULT>

Installed patch modules:
kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

    O exemplo de saída acima mostra que um módulo de correção de kernel ainda está instalado, mas o kernel não está corrigido.

Recursos adicionais

  • Para mais informações sobre o utilitário de linha de comando kpatch, consulte a página do manual kpatch(1).
  • Para mais informações sobre o gerenciador de sistemas e serviços systemd, arquivos de configuração de unidades, suas localizações, assim como uma lista completa de systemd tipos de unidades, veja as seções relevantes em Configuring basic system settings.

Capítulo 9. Estabelecendo limites para aplicações

Como administrador de sistemas, use a funcionalidade do kernel dos grupos de controle para definir limites, priorizar ou isolar os recursos de hardware dos processos de modo que as aplicações em seu sistema sejam estáveis e não fiquem sem memória.

9.1. Entendendo os grupos de controle

Control groups é um recurso do kernel Linux que permite organizar processos em grupos hierarquicamente ordenados - cgroups. A hierarquia (árvore de grupos de controle) é definida fornecendo estrutura para cgroups sistema de arquivo virtual, montado por padrão no diretório /sys/fs/cgroup/. Ela é feita manualmente através da criação e remoção de subdiretórios em /sys/fs/cgroup/. Alternativamente, utilizando o sistema systemd e o gerente de serviços.

Os controladores de recursos (um componente do kernel) modificam então o comportamento dos processos em cgroups limitando, priorizando ou alocando recursos do sistema (tais como tempo de CPU, memória, largura de banda de rede ou várias combinações) desses processos.

O valor agregado de cgroups é a agregação de processos que permite a divisão de recursos de hardware entre aplicações e usuários. Assim, é possível obter um aumento na eficiência geral, estabilidade e segurança do ambiente dos usuários.

Grupos de controle versão 1

Control groups version 1 (cgroups-v1) fornece uma hierarquia de controladores por recurso. Isso significa que cada recurso, como CPU, memória, E/S, etc., tem sua própria hierarquia de grupo de controle. É possível combinar diferentes hierarquias de grupos de controle de uma forma que um controlador possa coordenar com outro na administração de seus respectivos recursos. Entretanto, os dois controladores podem pertencer a hierarquias de processo diferentes, o que não permite sua coordenação adequada.

Os controladores cgroups-v1 foram desenvolvidos em um grande período de tempo e, como resultado, o comportamento e a nomenclatura de seus arquivos de controle não é uniforme.

Grupos de controle versão 2

Os problemas com a coordenação do controlador, decorrentes da flexibilidade da hierarquia, levaram ao desenvolvimento do site control groups version 2.

Control groups version 2 (cgroups-v2) fornece uma hierarquia de grupo de controle única contra a qual todos os controladores de recursos são montados.

O comportamento do arquivo de controle e a nomeação é consistente entre os diferentes controladores.

Atenção

A RHEL 8 fornece cgroups-v2 como uma previsão tecnológica com um número limitado de controladores de recursos. Para mais informações sobre os controladores de recursos relevantes, consulte o cgroups-v2 release note.

Esta subseção foi baseada em uma apresentação do Devconf.cz 2019.[1]

Recursos adicionais

9.2. O que são controladores de recursos do kernel

A funcionalidade dos grupos de controle é habilitada pelos controladores de recursos do kernel. A RHEL 8 suporta vários controladores para control groups version 1 (cgroups-v1) e control groups version 2 (cgroups-v2).

Um controlador de recursos, também chamado de subsistema de grupo de controle, é um subsistema de kernel que representa um único recurso, como tempo de CPU, memória, largura de banda de rede ou E/S de disco. O kernel Linux fornece uma gama de controladores de recursos que são montados automaticamente pelo sistema systemd e pelo gerenciador de serviços. Encontre uma lista dos controladores de recursos atualmente montados no arquivo /proc/cgroups.

Os seguintes controladores estão disponíveis para cgroups-v1:

  • blkio - pode estabelecer limites no acesso de entrada/saída de e para os dispositivos de bloco.
  • cpu - pode ajustar os parâmetros do Agendador de Programação Completamente Justo (CFS) para as tarefas do grupo de controle. Ele é montado junto com o controlador cpuacct na mesma montagem.
  • cpuacct - cria relatórios automáticos sobre os recursos da CPU utilizados por tarefas em um grupo de controle. É montado junto com o controlador cpu na mesma montagem.
  • cpuset - pode ser usado para restringir as tarefas do grupo de controle para executar somente em um subconjunto específico de CPUs e para direcionar as tarefas para usar a memória somente em nós de memória especificados.
  • devices - pode controlar o acesso a dispositivos para tarefas em um grupo de controle.
  • freezer - pode ser usado para suspender ou retomar tarefas em um grupo de controle.
  • memory - pode ser usado para estabelecer limites no uso de memória por tarefas em um grupo de controle e gera relatórios automáticos sobre os recursos de memória utilizados por essas tarefas.
  • net_cls - tags pacotes de rede com um identificador de classe (classid) que permite ao controlador de tráfego Linux (o comando tc ) identificar pacotes que se originam de uma determinada tarefa do grupo de controle. Um subsistema de net_cls, o net_filter (iptables), também pode usar esta tag para realizar ações em tais pacotes. O net_filter marca tomadas de rede com um identificador de firewall (fwid) que permite que o firewall Linux (através do comando iptables ) identifique pacotes originados de uma tarefa específica do grupo de controle.
  • net_prio - estabelece a prioridade do tráfego na rede.
  • pids - pode estabelecer limites para uma série de processos e seus filhos em um grupo de controle.
  • perf_event - pode agrupar tarefas para monitoramento pelo utilitário de monitoramento e relatórios de desempenho perf.
  • rdma - pode estabelecer limites para os recursos específicos de Remote Direct Memory Access/InfiniBand em um grupo de controle.
  • hugetlb - pode ser usado para limitar o uso de páginas de memória virtual de grande tamanho por tarefas em um grupo de controle.

Os seguintes controladores estão disponíveis para cgroups-v2:

  • io - Um acompanhamento para blkio de cgroups-v1.
  • memory - Um acompanhamento para memory de cgroups-v1.
  • pids - O mesmo que pids em cgroups-v1.
  • rdma - O mesmo que rdma em cgroups-v1.
  • cpu - Um acompanhamento para cpu e cpuacct de cgroups-v1.
  • cpuset - Suporta apenas a funcionalidade central (cpus{,.effective}, mems{,.effective}) com uma nova funcionalidade de partição.
  • perf_event - O suporte é inerente, nenhum arquivo de controle explícito. Você pode especificar um v2 cgroup como parâmetro para o comando perf que irá traçar o perfil de todas as tarefas dentro desse cgroup.
Importante

Um controlador de recursos pode ser usado tanto em uma hierarquia cgroups-v1 quanto em uma hierarquia cgroups-v2, não simultaneamente em ambas.

Recursos adicionais

  • Para mais informações sobre controladores de recursos em geral, consulte a página do manual cgroups(7).
  • Para descrições detalhadas dos controladores de recursos específicos, consulte a documentação no diretório /usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/.
  • Para mais informações sobre cgroups-v2, consulte a página do manual cgroups(7).

9.3. Usando grupos de controle através de um sistema de arquivo virtual

Você pode usar control groups (cgroups) para estabelecer limites, priorizar ou controlar o acesso aos recursos de hardware para grupos de processos. Isto permite que você controle granularmente o uso de recursos de aplicações para utilizá-los de forma mais eficiente. As seções seguintes fornecem uma visão geral das tarefas relacionadas ao gerenciamento do cgroups tanto para a versão 1 como para a versão 2, utilizando um sistema de arquivo virtual.

9.3.1. Definição de limites de CPU para aplicações usando cgroups-v1

Às vezes uma aplicação consome muito tempo de CPU, o que pode ter um impacto negativo na saúde geral de seu ambiente. Use o sistema de arquivo virtual /sys/fs/ para configurar os limites da CPU para uma aplicação usando control groups version 1 (cgroups-v1).

Pré-requisitos

  • Uma aplicação cujo consumo de CPU você deseja restringir.

  • Verifique se os controladores do cgroups-v1 foram montados: 

    # mount -l | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
...

Procedimento

  1. Identificar o ID do processo (PID) da aplicação que você deseja restringir no consumo da CPU: 

    # top
top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
%Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
 5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
 6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
    1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
  505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
...

    O exemplo de saída do programa top revela que PID 6955 (aplicação ilustrativa sha1sum) consome muitos recursos de CPU.

  2. Criar um subdiretório no diretório do controlador de recursos cpu: 

    # mkdir /sys/fs/cgroup/cpu/Example/

    O diretório acima representa um grupo de controle, onde você pode colocar processos específicos e aplicar certos limites de CPU aos processos. Ao mesmo tempo, alguns arquivos de interface cgroups-v1 e cpu arquivos específicos do controlador serão criados no diretório.

  3. Opcionalmente, inspecionar o grupo de controle recém-criado: 

    # ll /sys/fs/cgroup/cpu/Example/
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
-rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
-r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
-rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
-rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

    O exemplo de saída mostra arquivos, tais como cpuacct.usage, cpu.cfs._period_us, que representam configurações e/ou limites específicos, que podem ser definidos para processos no grupo de controle Example. Observe que os respectivos nomes de arquivos são prefixados com o nome do controlador do grupo de controle ao qual pertencem.

    Por padrão, o grupo de controle recém-criado herda o acesso a todos os recursos da CPU do sistema sem um limite.

  4. Configurar os limites da CPU para o grupo de controle: 

    # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
# echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

    O arquivo cpu.cfs_period_us representa um período de tempo em microssegundos (µs, aqui representado como "us") para a freqüência com que o acesso de um grupo de controle aos recursos da CPU deve ser realocado. O limite superior é de 1 segundo e o limite inferior é de 1000 microssegundos.

    O arquivo cpu.cfs_quota_us representa a quantidade total de tempo em microssegundos para o qual todos os processos em um grupo de controle podem ser executados coletivamente durante um período (como definido por cpu.cfs_period_us). Assim que os processos em um grupo de controle, durante um único período, esgotam todo o tempo especificado pela cota, eles são acelerados para o restante do período e não podem ser executados até o período seguinte. O limite inferior é de 1000 microssegundos.

    Os comandos do exemplo acima estabelecem os limites de tempo da CPU para que todos os processos coletivamente no grupo de controle Example possam ser executados apenas por 0,2 segundos (definido por cpu.cfs_quota_us) a cada 1 segundo (definido por cpu.cfs_period_us).

  5. Opcionalmente, verificar os limites: 

    # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
1000000
200000

  6. Adicione o PID do aplicativo ao grupo de controle Example: 

    # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs

or

# echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

    O comando anterior assegura que uma aplicação desejada se torne um membro do grupo de controle Example e, portanto, não exceda os limites de CPU configurados para o grupo de controle Example. O PID deve representar um processo existente no sistema. O PID 6955 aqui foi atribuído ao processo sha1sum /dev/zero &, utilizado para ilustrar o caso de uso do controlador cpu.

  7. Verificar se a aplicação é executada no grupo de controle especificado: 

    # cat /proc/6955/cgroup
12:cpuset:/
11:hugetlb:/
10:net_cls,net_prio:/
9:memory:/user.slice/user-1000.slice/user@1000.service
8:devices:/user.slice
7:blkio:/
6:freezer:/
5:rdma:/
4:pids:/user.slice/user-1000.slice/user@1000.service
3:perf_event:/
2:cpu,cpuacct:/Example
1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

    O exemplo acima mostra que o processo da aplicação desejada é executado no grupo de controle Example, que aplica limites de CPU ao processo da aplicação.

  8. Identificar o consumo atual da CPU de sua aplicação acelerada: 

    # top
top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
 5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
 6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
  505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
 4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
...

    Observe que o consumo de CPU do PID 6955 diminuiu de 99% para 20%.

Recursos adicionais

9.3.2. Definição de limites de CPU para aplicações usando cgroups-v2

Às vezes uma aplicação utiliza muito tempo de CPU, o que pode ter um impacto negativo na saúde geral de seu ambiente. Use control groups version 2 (cgroups-v2) para configurar limites de CPU para a aplicação, e restringir seu consumo.

Pré-requisitos

Procedimento

  1. Evitar que cgroups-v1 seja montado automaticamente durante a inicialização do sistema: 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="cgroup_no_v1=all"

    O comando adiciona um parâmetro de linha de comando do kernel à entrada de inicialização atual. O parâmetro cgroup_no_v1=all impede que cgroups-v1 seja montado automaticamente.

    Alternativamente, use o parâmetro de linha de comando do kernel systemd.unified_cgroup_hierarchy=1 para montar cgroups-v2 durante a inicialização do sistema por padrão.

    Nota

    A RHEL 8 apoia tanto cgroups-v1 como cgroups-v2. Entretanto, cgroups-v1 é habilitado e montado por padrão durante o processo de inicialização.

  2. Reinicie o sistema para que as mudanças entrem em vigor.

  3. Opcionalmente, verifique se a funcionalidade cgroups-v1 foi desativada: 

    # mount -l | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)

    Se cgroups-v1 tiver sido desativado com sucesso, a saída não mostra nenhuma referência "tipo cgroup", exceto aquelas que pertencem a systemd.

  4. Monte cgroups-v2 em qualquer parte do sistema de arquivos: 

    # mount -t cgroup2 none <MOUNT_POINT>

  5. Opcionalmente, verifique se a funcionalidade cgroups-v2 foi montada: 

    # mount -l | grep cgroup2
none on /cgroups-v2 type cgroup2 (rw,relatime,seclabel)

    O exemplo de saída mostra que cgroups-v2 foi montado no diretório /cgroups-v2/.

  6. Opcionalmente, inspecionar o conteúdo do diretório /cgroups-v2/: 

    # ll /cgroups-v2/
-r—​r—​r--. 1 root root 0 Mar 13 11:57 cgroup.controllers
-rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.max.depth
-rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.max.descendants
-rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.procs
-r—​r—​r--. 1 root root 0 Mar 13 11:57 cgroup.stat
-rw-r—​r--. 1 root root 0 Mar 13 11:58 cgroup.subtree_control
-rw-r—​r--. 1 root root 0 Mar 13 11:57 cgroup.threads
-rw-r—​r--. 1 root root 0 Mar 13 11:57 cpu.pressure
-r—​r—​r--. 1 root root 0 Mar 13 11:57 cpuset.cpus.effective
-r—​r—​r--. 1 root root 0 Mar 13 11:57 cpuset.mems.effective
-rw-r—​r--. 1 root root 0 Mar 13 11:57 io.pressure
-rw-r—​r--. 1 root root 0 Mar 13 11:57 memory.pressure

    O diretório /cgroups-v2/, também chamado de grupo de controle raiz, contém alguns arquivos de interface (começando por cgroup) e alguns arquivos específicos do controlador, como cpuset.cpus.effective.

  7. Identificar os IDs de processo (PIDs) das aplicações que você deseja restringir no consumo da CPU: 

    # top
top - 15:39:52 up  3:45,  1 user,  load average: 0.79, 0.20, 0.07
Tasks: 265 total,   3 running, 262 sleeping,   0 stopped,   0 zombie
%Cpu(s): 74.3 us,  6.1 sy,  0.0 ni, 19.4 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
MiB Mem :   1826.8 total,    243.8 free,   1102.1 used,    480.9 buff/cache
MiB Swap:   1536.0 total,   1526.2 free,      9.8 used.    565.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5473 root      20   0  228440   1740   1456 R  99.7   0.1   0:12.11 sha1sum
 5439 root      20   0  222616   3420   3052 R  60.5   0.2   0:27.08 cpu_load_generator
 2170 jdoe      20   0 3600716 209960  67548 S   0.3  11.2   1:18.50 gnome-shell
 3051 root      20   0  274424   3976   3092 R   0.3   0.2   1:01.25 top
    1 root      20   0  245448  10256   5448 S   0.0   0.5   0:02.52 systemd
...

    O exemplo de saída do programa top revela que PID 5473 e 5439 (aplicação ilustrativa sha1sum e cpu_load_generator) consomem muitos recursos, ou seja, CPU. Ambos são exemplos de aplicações utilizadas para demonstrar o gerenciamento da funcionalidade cgroups-v2.

  8. Habilitar os controladores relacionados à CPU: 

    # echo "+cpu" > /cgroups-v2/cgroup.subtree_control
# echo "+cpuset" > /cgroups-v2/cgroup.subtree_control

    Os comandos anteriores habilitam os controladores cpu e cpuset para os grupos de sub-controle imediatos do grupo de controle raiz /cgroups-v2/.

  9. Crie um subdiretório no diretório /cgroups-v2/ previamente criado: 

    # mkdir /cgroups-v2/Example/

    O diretório /cgroups-v2/Example/ representa um grupo de sub-controle, onde você pode colocar processos específicos e aplicar vários limites de CPU aos processos. Além disso, a etapa anterior habilitou os controladores cpu e cpuset para este grupo de sub-controle.

    No momento da criação de /cgroups-v2/Example/, alguns cgroups-v2 arquivos de interface e cpu e cpuset arquivos específicos do controlador serão criados no diretório.

  10. Opcionalmente, inspecionar o grupo de controle recém-criado: 

    # ll /cgroups-v2/Example/
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.controllers
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.events
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.freeze
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.max.depth
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.max.descendants
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.procs
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cgroup.stat
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.subtree_control
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.threads
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cgroup.type
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.max
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.pressure
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.effective
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.cpus.partition
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpuset.mems
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cpuset.mems.effective
-r—​r—​r--. 1 root root 0 Mar 13 14:48 cpu.stat
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.weight
-rw-r—​r--. 1 root root 0 Mar 13 14:48 cpu.weight.nice
-rw-r—​r--. 1 root root 0 Mar 13 14:48 io.pressure
-rw-r—​r--. 1 root root 0 Mar 13 14:48 memory.pressure

    O exemplo de saída mostra arquivos como cpuset.cpus e cpu.max. Os arquivos são específicos para os controladores cpuset e cpu que você habilitou para os grupos de controle infantil direto da raiz (/cgroups-v2/) usando o arquivo /cgroups-v2/cgroup.subtree_control. Além disso, há arquivos de interface de controle cgroup gerais como cgroup.procs ou cgroup.controllers, que são comuns a todos os grupos de controle, independentemente dos controladores habilitados.

    Por padrão, o recém-criado grupo de sub-controle herdou o acesso a todos os recursos da CPU do sistema sem um limite.

  11. Certifique-se de que os processos que você deseja limitar competem pelo tempo de CPU na mesma CPU: 

    # echo "1" > /cgroups-v2/Example/cpuset.cpus

    O comando anterior assegura os processos que você colocou no grupo de sub-controle Example, competindo na mesma CPU. Esta configuração é importante para que o controlador cpu seja ativado.

    Importante

    O controlador cpu só é ativado se o grupo de sub-controle relevante tiver pelo menos 2 processos, que competem pelo tempo em uma única CPU.

  12. Configurar os limites da CPU do grupo de controle: 

    # echo "200000 1000000" > /cgroups-v2/Example/cpu.max

    O primeiro valor é a quota de tempo permitida em microssegundos para a qual todos os processos coletivamente em um grupo de sub-controle podem ser executados durante um período (especificado pelo segundo valor). Durante um único período, quando os processos em um grupo de controle esgotam coletivamente todo o tempo especificado por esta cota, eles são acelerados durante o restante do período e não podem funcionar até o período seguinte.

    O comando exemplo estabelece os limites de tempo da CPU para que todos os processos coletivamente no grupo de sub-controle Example possam ser executados na CPU apenas por 0,2 segundos a cada 1 segundo.

  13. Opcionalmente, verificar os limites: 

    # cat /cgroups-v2/Example/cpu.max
200000 1000000

  14. Adicione os PIDs das aplicações ao grupo de sub-controle Example: 

    # echo "5473" > /cgroups-v2/Example/cgroup.procs
# echo "5439" > /cgroups-v2/Example/cgroup.procs

    Os comandos de exemplo asseguram que as aplicações desejadas se tornem membros do grupo de sub-controle Example e, portanto, não excedam os limites de CPU configurados para o grupo de sub-controle Example.

  15. Verificar se as aplicações são executadas no grupo de controle especificado: 

    # cat /proc/5473/cgroup /proc/5439/cgroup
1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
0::/Example
1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
0::/Example

    O exemplo de saída acima mostra que os processos das aplicações desejadas são executados no grupo de sub-controle Example.

  16. Inspecione o consumo atual da CPU de suas aplicações aceleradas: 

    # top
top - 15:56:27 up  4:02,  1 user,  load average: 0.03, 0.41, 0.55
Tasks: 265 total,   4 running, 261 sleeping,   0 stopped,   0 zombie
%Cpu(s):  9.6 us,  0.8 sy,  0.0 ni, 89.4 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
MiB Mem :   1826.8 total,    243.4 free,   1102.1 used,    481.3 buff/cache
MiB Swap:   1536.0 total,   1526.2 free,      9.8 used.    565.5 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5439 root      20   0  222616   3420   3052 R  10.0   0.2   6:15.83 cpu_load_generator
 5473 root      20   0  228440   1740   1456 R  10.0   0.1   9:20.65 sha1sum
 2753 jdoe      20   0  743928  35328  20608 S   0.7   1.9   0:20.36 gnome-terminal-
 2170 jdoe      20   0 3599688 208820  67552 S   0.3  11.2   1:33.06 gnome-shell
 5934 root      20   0  274428   5064   4176 R   0.3   0.3   0:00.04 top
 ...

    Observe que o consumo de CPU para os sites PID 5439 e PID 5473 diminuiu para 10%. O grupo de sub-controle Example limita seus processos a 20% do tempo da CPU coletivamente. Como existem 2 processos no grupo de controle, cada um pode utilizar 10% do tempo da CPU.

Recursos adicionais

9.4. Papel do sistemad em grupos de controle versão 1

O Red Hat Enterprise Linux 8 move as configurações de gerenciamento de recursos do nível de processo para o nível de aplicação, ligando o sistema de hierarquias cgroup com a árvore de unidades systemd. Portanto, você pode gerenciar os recursos do sistema com o comando systemctl, ou modificando os arquivos da unidade systemd.

Por padrão, o gerente de sistemas e serviços systemd faz uso do slice, das unidades scope e service para organizar e estruturar os processos nos grupos de controle. O comando systemctl permite modificar ainda mais esta estrutura através da criação do slices personalizado. Além disso, systemd monta automaticamente hierarquias para importantes controladores de recursos do kernel no diretório /sys/fs/cgroup/.

Três tipos de unidade systemd são usados para o controle de recursos:

  • Service - Um processo ou um grupo de processos, que systemd começou de acordo com um arquivo de configuração de unidade. Os serviços encapsulam os processos especificados para que eles possam ser iniciados e parados como um conjunto. Os serviços são nomeados da seguinte forma: 

    <name>.service

  • Scope - Um grupo de processos criados externamente. Os escopos encapsulam processos que são iniciados e interrompidos pelos processos arbitrários através da função fork() e depois registrados por systemd em tempo de execução. Por exemplo, sessões de usuários, contêineres e máquinas virtuais são tratados como escopos. Os escopos são nomeados da seguinte forma: 

    <name>.scope

  • Slice - Um grupo de unidades organizadas hierarquicamente. As fatias organizam uma hierarquia na qual são colocados os escopos e serviços. Os processos reais estão contidos em escopos ou em serviços. Cada nome de uma unidade de fatias corresponde ao caminho para um local na hierarquia. O traço ("-") funciona como um separador dos componentes do caminho para uma fatia da fatia da raiz de -.slice. No exemplo a seguir: 

    <parent-name>.slice

    parent-name.slice é uma subplaca de parent.slice, que é uma subplaca da fatia de raiz de -.slice. parent-name.slice pode ter sua própria subplaca chamada parent-name-name2.slice, e assim por diante.

As unidades service, scope, e slice mapeiam diretamente os objetos da hierarquia do grupo de controle. Quando estas unidades são ativadas, elas mapeiam diretamente para os caminhos do grupo de controle construídos a partir dos nomes das unidades.

O seguinte é um exemplo abreviado de uma hierarquia de grupo de controle: 

Control group /:
-.slice
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 967 gdm-session-worker [pam/gdm-launch-environment]
│ │ │ ├─1035 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1054 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -background none -noreset -keeptty -verbose 3
│ │ │ ├─1212 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1369 /usr/bin/gnome-shell
│ │ │ ├─1732 ibus-daemon --xim --panel disable
│ │ │ ├─1752 /usr/libexec/ibus-dconf
│ │ │ ├─1762 /usr/libexec/ibus-x11 --kill-daemon
│ │ │ ├─1912 /usr/libexec/gsd-xsettings
│ │ │ ├─1917 /usr/libexec/gsd-a11y-settings
│ │ │ ├─1920 /usr/libexec/gsd-clipboard
…​
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
└─system.slice
  ├─rngd.service
  │ └─800 /sbin/rngd -f
  ├─systemd-udevd.service
  │ └─659 /usr/lib/systemd/systemd-udevd
  ├─chronyd.service
  │ └─823 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─761 /sbin/auditd
  │ └─763 /usr/sbin/sedispatch
  ├─accounts-daemon.service
  │ └─876 /usr/libexec/accounts-daemon
  ├─example.service
  │ ├─ 929 /bin/bash /home/jdoe/example.sh
  │ └─4902 sleep 1
  …​

O exemplo acima mostra que os serviços e escopos contêm processos e são colocados em fatias que não contêm processos próprios.

Recursos adicionais

  • Para mais informações sobre systemd, arquivos de unidades e uma lista completa de systemd tipos de unidades, veja as seções relevantes em Configuring basic system settings.
  • Para mais informações sobre controladores de recursos, consulte a seção O que são controladores de recursos do kernel e as páginas do manual systemd.resource-control(5), cgroups(7).
  • Para mais informações sobre fork(), consulte as páginas do manual fork(2).

9.5. Usando grupos de controle versão 1 com systemd

As seções seguintes fornecem uma visão geral das tarefas relacionadas à criação, modificação e remoção dos grupos de controle (cgroups). As utilidades fornecidas pelo sistema systemd e pelo gerente de serviços são a forma preferida da gerência cgroups e serão suportadas no futuro.

9.5.1. Criação de grupos de controle versão 1 com systemd

Você pode usar o sistema systemd e o gerente de serviços para criar grupos de controle transientes e persistentes (cgroups) para estabelecer limites, priorizar ou controlar o acesso aos recursos de hardware para grupos de processos.

9.5.1.1. Criação de grupos de controle transientes

A cgroups estabelece limites para os recursos consumidos por uma unidade (serviço ou escopo) durante seu tempo de execução.

Procedimento

  • Para criar um grupo de controle transitório, use o comando systemd-run no seguinte formato: 

    # systemd-run --unit=<name> --slice=<name>.slice <command>

    Este comando cria e inicia um serviço transitório ou uma unidade de escopo e executa um comando personalizado em tal unidade.

    • A opção --unit=<name> dá um nome à unidade. Se --unit não for especificado, o nome é gerado automaticamente.
    • O --slice=<name>.slice faz de sua unidade de serviço ou escopo um membro de uma fatia especificada. Substitua <name>.slice com o nome de uma fatia existente (como mostrado na saída de systemctl -t slice), ou criar uma nova fatia passando um nome único. Por padrão, os serviços e escopos são criados como membros do system.slice.

    • Substitua <command> com o comando que você deseja executar no serviço ou na unidade de escopo.

      A seguinte mensagem é exibida para confirmar que você criou e iniciou o serviço ou o escopo com sucesso: 

      # Funcionando como unidade <name>.service

  • Opcionalmente, manter a unidade funcionando após a conclusão de seus processos para coletar informações sobre o tempo de execução: 

    # systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>

    O comando cria e inicia uma unidade de serviço transitória e executa um comando personalizado em tal unidade. A opção --remain-after-exit garante que o serviço continue funcionando após a conclusão de seus processos.

Recursos adicionais

9.5.1.2. Criação de grupos de controle persistentes

Para atribuir um grupo de controle persistente a um serviço, é necessário editar seu arquivo de configuração de unidade. A configuração é preservada após o reinício do sistema, para que possa ser usada para gerenciar serviços que são iniciados automaticamente.

Procedimento

  • Para criar um grupo de controle persistente, execute: 

    # systemctl enable <name>.service

    O comando acima cria automaticamente um arquivo de configuração de unidade no diretório /usr/lib/systemd/system/ e por padrão, ele atribui <name>.service para a unidade system.slice.

Recursos adicionais

9.5.2. Modificação de grupos de controle versão 1 com systemd

Cada unidade persistente é supervisionada pelo gerente de sistema e serviços systemd, e tem um arquivo de configuração da unidade no diretório /usr/lib/systemd/system/. Para alterar as configurações de controle de recursos das unidades persistentes, modifique seu arquivo de configuração de unidade manualmente em um editor de texto ou a partir da interface de linha de comando.

9.5.2.1. Configuração das configurações de controle de recursos de memória na linha de comando

A execução de comandos na interface de linha de comando é uma das formas de estabelecer limites, priorizar ou controlar o acesso aos recursos de hardware para grupos de processos.

Procedimento

  • Para limitar o uso de memória de um serviço, execute o seguinte: 

    # systemctl set-property example.service MemoryLimit=1500K

    O comando atribui instantaneamente o limite de memória de 1.500 kilobytes aos processos executados em um grupo de controle ao qual o serviço example.service pertence. O parâmetro MemoryLimit, nesta variante de configuração, é definido no arquivo /etc/systemd/system.control/example.service.d/50-MemoryLimit.conf e controla o valor do arquivo /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes.

  • Opcionalmente, para limitar temporariamente o uso de memória de um serviço, executar: 

    # systemctl set-property --runtime example.service MemoryLimit=1500K

    O comando atribui instantaneamente o limite de memória ao serviço example.service. O parâmetro MemoryLimit é definido até a próxima reinicialização no arquivo /run/systemd/system.control/example.service.d/50-MemoryLimit.conf. Com uma reinicialização, todo o diretório /run/systemd/system.control/ e MemoryLimit são removidos.

Nota

O arquivo 50-MemoryLimit.conf armazena o limite de memória como um múltiplo de 4096 bytes - um tamanho de página de kernel específico para AMD64 e Intel 64. O número real de bytes depende de uma arquitetura de CPU.

Recursos adicionais

9.5.2.2. Configuração das configurações de controle de recursos de memória com arquivos de unidade

A modificação manual dos arquivos da unidade é uma das formas de estabelecer limites, priorizar ou controlar o acesso aos recursos de hardware para grupos de processos.

Procedimento

  1. Para limitar o uso de memória de um serviço, modifique o arquivo /usr/lib/systemd/system/example.service como segue: 

    …​
[Service]
MemoryLimit=1500K
…​

    A configuração acima coloca um limite ao consumo máximo de memória dos processos executados em um grupo de controle, do qual faz parte example.service.

    Nota

    Use os sufixos K, M, G ou T para identificar Kilobyte, Megabyte, Gigabyte ou Terabyte como uma unidade de medida.

  2. Recarregar todos os arquivos de configuração da unidade: 

    # systemctl daemon-reload

  3. Reinicie o serviço: 

    # systemctl restart example.service
  4. Reinicie o sistema.

  5. Opcionalmente, verifique se as mudanças entraram em vigor: 

    # cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
1536000

    O exemplo mostra que o consumo de memória foi limitado em cerca de 1.500 Kilobytes.

    Nota

    O arquivo memory.limit_in_bytes armazena o limite de memória como um múltiplo de 4096 bytes - um tamanho de página de kernel específico para AMD64 e Intel 64. O número real de bytes depende de uma arquitetura de CPU.

Recursos adicionais

9.5.3. Remoção de grupos de controle versão 1 com systemd

Você pode usar o sistema systemd e o gerente de serviços para remover grupos de controle transientes e persistentes (cgroups) se você não precisar mais limitar, priorizar ou controlar o acesso aos recursos de hardware para grupos de processos.

9.5.3.1. Remoção de grupos de controle transientes

O cgroups transitório é liberado automaticamente quando todos os processos que uma unidade de serviço ou de escopo contém, terminam.

Procedimento

  • Para parar a unidade de serviço com todos os seus processos, execute: 

    # systemctl stop <name>.service

  • Para encerrar um ou mais processos da unidade, execute: 

    # systemctl kill <name>.service --kill-who=PID,…​ --signal=signal

    O comando acima usa a opção --kill-who para selecionar processo(s) do grupo de controle que você deseja encerrar. Para matar vários processos ao mesmo tempo, passe uma lista de PIDs separada por vírgula. A opção --signal determina o tipo de sinal POSIX a ser enviado para os processos especificados. O sinal padrão é SIGTERM.

Recursos adicionais

9.5.3.2. Remoção de grupos de controle persistentes

Persistentes cgroups são liberados quando um serviço ou uma unidade de escopo é parada ou desativada e seu arquivo de configuração é excluído.

Procedimento

  1. Parar a unidade de serviço: 

    # systemctl stop <name>.service

  2. Desativar a unidade de serviço: 

    # systemctl disable <name>.service

  3. Remover o arquivo de configuração da unidade relevante: 

    # rm /usr/lib/systemd/system/<name>.service

  4. Recarregar todos os arquivos de configuração da unidade para que as mudanças entrem em vigor: 

    # systemctl daemon-reload

Recursos adicionais

9.6. Obtenção de informações sobre grupos de controle versão 1

As seções seguintes descrevem como exibir várias informações sobre grupos de controle (cgroups):

  • Listagem das unidades systemd e visualização de seu status
  • Visualizando a hierarquia cgroups
  • Monitoramento do consumo de recursos em tempo real

9.6.1. Unidades do sistema de listagem

O procedimento a seguir descreve como utilizar o sistema systemd e o gerente de serviços para listar suas unidades.

Pré-requisitos

Procedimento

  • Para listar todas as unidades ativas no sistema, execute o comando # systemctl e o terminal retornará uma saída semelhante ao exemplo a seguir: 

    # systemctl
UNIT                                                LOAD   ACTIVE SUB       DESCRIPTION
…​
init.scope                                          loaded active running   System and Service Manager
session-2.scope                                     loaded active running   Session 2 of user jdoe
abrt-ccpp.service                                   loaded active exited    Install ABRT coredump hook
abrt-oops.service                                   loaded active running   ABRT kernel log watcher
abrt-vmcore.service                                 loaded active exited    Harvest vmcores for ABRT
abrt-xorg.service                                   loaded active running   ABRT Xorg log watcher
…​
-.slice                                             loaded active active    Root Slice
machine.slice                                       loaded active active    Virtual Machine and Container Slice system-getty.slice                                                                       loaded active active    system-getty.slice
system-lvm2\x2dpvscan.slice                         loaded active active    system-lvm2\x2dpvscan.slice
system-sshd\x2dkeygen.slice                         loaded active active    system-sshd\x2dkeygen.slice
system-systemd\x2dhibernate\x2dresume.slice         loaded active active    system-systemd\x2dhibernate\x2dresume>
system-user\x2druntime\x2ddir.slice                 loaded active active    system-user\x2druntime\x2ddir.slice
system.slice                                        loaded active active    System Slice
user-1000.slice                                     loaded active active    User Slice of UID 1000
user-42.slice                                       loaded active active    User Slice of UID 42
user.slice                                          loaded active active    User and Session Slice
…​
    • UNIT - um nome de uma unidade que também reflete a posição da unidade em uma hierarquia de grupo de controle. As unidades relevantes para o controle de recursos são um slice, um scope, e um service.
    • LOAD - indica se o arquivo de configuração da unidade foi carregado corretamente. Se o arquivo da unidade não foi carregado, o campo contém o estado error ao invés de loaded. Outros estados de carga da unidade são: stub , merged, e masked.
    • ACTIVE - o estado de ativação da unidade de alto nível, que é uma generalização de SUB.
    • SUB - o estado de ativação da unidade de baixo nível. O intervalo de valores possíveis depende do tipo de unidade.
    • DESCRIPTION - a descrição do conteúdo e da funcionalidade da unidade.

  • Para listar as unidades inativas, execute: 

    # systemctl --all

  • Para limitar a quantidade de informações na saída, execute: 

    # systemctl --type service,masked

    A opção --type requer uma lista separada por vírgula dos tipos de unidades, como service e slice, ou estados de carga unitária, como loaded e masked.

Recursos adicionais

  • Para mais informações sobre systemd, arquivos de unidades e uma lista completa de systemd tipos de unidades, veja as seções relevantes em Configuring basic system settings.

9.6.2. Visualizando uma hierarquia de grupo de controle versão 1

O seguinte procedimento descreve como exibir a hierarquia dos grupos de controle (cgroups) e os processos em execução em específico cgroups.

Pré-requisitos

Procedimento

  • Para exibir toda a hierarquia cgroups em seu sistema, execute # systemd-cgls: 

    # systemd-cgls
Control group /:
-.slice
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
│ │ │ ├─1040 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
…​
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
└─system.slice
  …​
  ├─example.service
  │ ├─6882 /bin/bash /home/jdoe/example.sh
  │ └─6902 sleep 1
  ├─systemd-journald.service
    └─629 /usr/lib/systemd/systemd-journald
  …​

    O exemplo de saída retorna toda a hierarquia cgroups, onde o nível mais alto é formado por slices.

  • Para exibir a hierarquia cgroups filtrada por um controlador de recursos, execute # systemd-cgls <resource_controller>: 

    # systemd-cgls memory
Controller memory; Control group /:
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
…​
└─system.slice
  |
  …​
  ├─chronyd.service
  │ └─844 /usr/sbin/chronyd
  ├─example.service
  │ ├─8914 /bin/bash /home/jdoe/example.sh
  │ └─8916 sleep 1
  …​

    O exemplo de saída do comando acima lista os serviços que interagem com o controlador selecionado.

  • Para exibir informações detalhadas sobre uma determinada unidade e sua parte da hierarquia cgroups, execute # systemctl status <system_unit>: 

    # systemctl status example.service
● example.service - My example service
   Loaded: loaded (/usr/lib/systemd/system/example.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-04-16 12:12:39 CEST; 3s ago
 Main PID: 17737 (bash)
    Tasks: 2 (limit: 11522)
   Memory: 496.0K (limit: 1.5M)
   CGroup: /system.slice/example.service
           ├─17737 /bin/bash /home/jdoe/example.sh
           └─17743 sleep 1
Apr 16 12:12:39 redhat systemd[1]: Started My example service.
Apr 16 12:12:39 redhat bash[17737]: The current time is Tue Apr 16 12:12:39 CEST 2019
Apr 16 12:12:40 redhat bash[17737]: The current time is Tue Apr 16 12:12:40 CEST 2019

Recursos adicionais

9.6.3. Visualizando os controladores de recursos

O procedimento a seguir descreve como aprender quais processos utilizam quais controladores de recursos.

Pré-requisitos

Procedimento

  1. Para ver com quais controladores de recursos um processo interage, execute o # cat proc/<PID>/cgroup comando: 

    # cat /proc/11269/cgroup
12:freezer:/
11:cpuset:/
10:devices:/system.slice
9:memory:/system.slice/example.service
8:pids:/system.slice/example.service
7:hugetlb:/
6:rdma:/
5:perf_event:/
4:cpu,cpuacct:/
3:net_cls,net_prio:/
2:blkio:/
1:name=systemd:/system.slice/example.service

    O exemplo de saída está relacionado a um processo de interesse. Neste caso, trata-se de um processo identificado por PID 11269, que pertence à unidade example.service. Você pode determinar se o processo foi colocado em um grupo de controle correto, como definido pelas especificações do arquivo da unidade systemd.

    Nota

    Por padrão, os itens e seus pedidos na lista de controladores de recursos são os mesmos para todas as unidades iniciadas por systemd, uma vez que ele monta automaticamente todos os controladores de recursos padrão.

Recursos adicionais

  • Para mais informações sobre controladores de recursos em geral, consulte as páginas do manual cgroups(7).
  • Para uma descrição detalhada dos controladores de recursos específicos, consulte a documentação no diretório /usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/.

9.6.4. Monitoramento do consumo de recursos

O procedimento a seguir descreve como visualizar uma lista dos grupos de controle atualmente em funcionamento (cgroups) e seu consumo de recursos em tempo real.

Pré-requisitos

Procedimento

  1. Para ver uma conta dinâmica de cgroups atualmente em execução, execute o comando # systemd-cgtop: 

    # systemd-cgtop
Control Group                            Tasks   %CPU   Memory  Input/s Output/s
/                                          607   29.8     1.5G        -        -
/system.slice                              125      -   428.7M        -        -
/system.slice/ModemManager.service           3      -     8.6M        -        -
/system.slice/NetworkManager.service         3      -    12.8M        -        -
/system.slice/accounts-daemon.service        3      -     1.8M        -        -
/system.slice/boot.mount                     -      -    48.0K        -        -
/system.slice/chronyd.service                1      -     2.0M        -        -
/system.slice/cockpit.socket                 -      -     1.3M        -        -
/system.slice/colord.service                 3      -     3.5M        -        -
/system.slice/crond.service                  1      -     1.8M        -        -
/system.slice/cups.service                   1      -     3.1M        -        -
/system.slice/dev-hugepages.mount            -      -   244.0K        -        -
/system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
/system.slice/dev-mqueue.mount               -      -    48.0K        -        -
/system.slice/example.service                2      -     2.0M        -        -
/system.slice/firewalld.service              2      -    28.8M        -        -
...

    O exemplo de saída exibe atualmente cgroups ordenado pelo uso de seus recursos (CPU, memória, carga de E/S em disco). A lista é atualizada a cada 1 segundo, por padrão. Portanto, oferece uma visão dinâmica da utilização real dos recursos de cada grupo de controle.

Recursos adicionais

  • Para mais informações sobre o monitoramento dinâmico do uso de recursos, consulte as páginas do manual systemd-cgtop(1).

9.7. O que são espaços de nomes

Namespaces são um dos métodos mais importantes para organizar e identificar objetos de software.

Um namespace envolve um recurso do sistema global (por exemplo, um ponto de montagem, um dispositivo de rede ou um nome de host) em uma abstração que faz parecer aos processos dentro do namespace que eles têm sua própria instância isolada do recurso global. Uma das tecnologias mais comuns que utilizam espaços de nomes são os recipientes.

As mudanças em um determinado recurso global são visíveis apenas para processos nesse espaço de nomes e não afetam o resto do sistema ou outros espaços de nomes.

Para inspecionar quais espaços de nome de um processo é membro, você pode verificar os links simbólicos no /proc/<PID>/ns/ diretório.

A tabela a seguir mostra os espaços de nomes e recursos suportados que eles isolam:

NamespaceIsolados

Mount

Pontos de montagem

UTS

Nome do host e nome de domínio NIS

IPC

Sistema V IPC, filas de mensagens POSIX

PID

Identificação do processo

Network

Dispositivos de rede, pilhas, portos, etc

User

IDs de usuário e de grupo

Control groups

Diretório raiz do grupo de controle

Recursos adicionais


[1] Linux Control Group v2 - Uma introdução, apresentação Devconf.cz 2019 por Waiman Long

Capítulo 10. Analisando o desempenho do sistema com a Coleção de Compiladores BPF

Como administrador de sistemas, use a biblioteca BPF Compiler Collection (BCC) para criar ferramentas para analisar o desempenho de seu sistema operacional Linux e coletar informações, que podem ser difíceis de obter através de outras interfaces.

10.1. Uma introdução ao BCC

BPF Compiler Collection (BCC) é uma biblioteca, que facilita a criação dos programas ampliados de Filtro de Pacotes Berkeley (eBPF). A principal utilidade dos programas eBPF é analisar o desempenho do sistema operacional e o desempenho da rede sem ter problemas de overhead ou de segurança.

BCC elimina a necessidade de os usuários conhecerem detalhes técnicos profundos do eBPF, e fornece muitos pontos de partida prontos para uso, tais como o pacote bcc-tools com programas eBPF pré-criados.

Nota

Os programas eBPF são acionados em eventos, tais como E/S de disco, conexões TCP e criações de processo. É improvável que os programas causem o colapso, loop ou tornem-se insensíveis por funcionarem em uma máquina virtual segura no kernel.

10.2. Instalando o pacote bcc-tools

Esta seção descreve como instalar o pacote bcc-tools, que também instala a biblioteca BPF Compiler Collection (BCC) como uma dependência.

Pré-requisitos

Procedimento

  1. Instale bcc-tools: 

    # yum install bcc-tools

    As ferramentas BCC estão instaladas no diretório /usr/share/bcc/tools/.

  2. Opcionalmente, inspecionar as ferramentas: 

    # ll /usr/share/bcc/tools/
...
-rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
-rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
-rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
-rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
-rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
-rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
-rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
...

    O diretório doc na lista acima contém documentação para cada ferramenta.

10.3. Utilização de ferramentas bcc selecionadas para análises de desempenho

Esta seção descreve como usar certos programas pré-criados da biblioteca da BPF Compiler Collection (BCC) para analisar de forma eficiente e segura o desempenho do sistema em cada evento. O conjunto de programas pré-criados na biblioteca do BCC pode servir como exemplos para a criação de programas adicionais.

Pré-requisitos

Usando o execsnoop para examinar os processos do sistema

  1. Executar o programa execsnoop em um terminal: 

    # /usr/share/bcc/tools/execsnoop

  2. Em outro terminal executar, por exemplo: 

    $ ls /usr/share/bcc/tools/doc/

    O acima exposto cria um processo de curta duração do comando ls.

  3. O terminal rodando execsnoop mostra a saída semelhante ao seguinte: 

    PCOMM	PID    PPID   RET ARGS
ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
...

    O programa execsnoop imprime uma linha de saída para cada novo processo, o que consome recursos do sistema. Ele até detecta processos de programas que rodam muito em breve, tais como ls, e a maioria das ferramentas de monitoramento não os registrariam.

    A saída execsnoop exibe os seguintes campos:

    • PCOMM - O nome do processo pai. (ls)
    • PID - A identificação do processo. (8382)
    • PPID - O ID do processo pai. (8287)
    • RET - O valor de retorno da chamada ao sistema exec() (0), que carrega o código do programa em novos processos.
    • ARGS - A localização do programa iniciado com argumentos.

Para ver mais detalhes, exemplos e opções para execsnoop, consulte o arquivo /usr/share/bcc/tools/doc/execsnoop_example.txt.

Para mais informações sobre exec(), consulte as páginas do manual exec(3).

Usando o opensnoop para rastrear quais arquivos um comando abre

  1. Executar o programa opensnoop em um terminal: 

    # /usr/share/bcc/tools/opensnoop -n uname

    A saída de impressões acima para arquivos, que são abertos somente pelo processo do comando uname.

  2. Em outro terminal executar: 

    $ uname

    O comando acima abre certos arquivos, que são capturados na próxima etapa.

  3. O terminal rodando opensnoop mostra a saída semelhante ao seguinte: 

    PID    COMM 	FD ERR PATH
8596   uname 	3  0   /etc/ld.so.cache
8596   uname 	3  0   /lib64/libc.so.6
8596   uname 	3  0   /usr/lib/locale/locale-archive
...

    O programa opensnoop observa a chamada do sistema open() em todo o sistema, e imprime uma linha de saída para cada arquivo que uname tentou abrir pelo caminho.

    A saída opensnoop exibe os seguintes campos:

    • PID - A identificação do processo. (8596)
    • COMM - O nome do processo. (uname)
    • FD - O descritor de arquivo - um valor que open() retorna para se referir ao arquivo aberto. (3)
    • ERR - Qualquer erro.

    • PATH - A localização dos arquivos que open() tentou abrir.

      Se um comando tentar ler um arquivo inexistente, então a coluna FD retorna -1 e a coluna ERR imprime um valor correspondente ao erro relevante. Como resultado, opensnoop pode ajudá-lo a identificar uma aplicação que não se comporta corretamente.

Para ver mais detalhes, exemplos e opções para opensnoop, consulte o arquivo /usr/share/bcc/tools/doc/opensnoop_example.txt.

Para mais informações sobre open(), consulte as páginas do manual open(2).

Utilização de biotop para examinar as operações de E/S no disco

  1. Executar o programa biotop em um terminal: 

    # /usr/share/bcc/tools/biotop 30

    O comando permite monitorar os processos superiores, que realizam operações de E/S no disco. O argumento garante que o comando produzirá um resumo de 30 segundos.

    Nota

    Quando nenhum argumento é fornecido, a tela de saída, por padrão, é atualizada a cada 1 segundo.

  2. Em outro terminal executar, por exemplo : 

    # dd if=/dev/vda of=/dev/zero

    O comando acima lê o conteúdo do dispositivo de disco rígido local e grava a saída para o arquivo /dev/zero. Esta etapa gera certo tráfego de E/S para ilustrar biotop.

  3. O terminal rodando biotop mostra a saída semelhante ao seguinte: 

    PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
9568   dd               R 252 0   vda      16294 14440636.0  3.69
48     kswapd0          W 252 0   vda       1763 120696.0    1.65
7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
7515   Xorg             R 252 0   vda        280  9940.0     0.28
7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
7807   gnome-software   R 252 0   vda         31  2336.0     0.73
9578   awk              R 252 0   vda         17  2228.0     0.66
7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
9581   pgrep            R 252 0   vda         58  1748.0     0.42
7531   InputThread      R 252 0   vda         30  1200.0     0.48
7504   gdbus            R 252 0   vda          3  1164.0     0.30
1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
...

    A saída biotop exibe os seguintes campos:

    • PID - A identificação do processo. (9568)
    • COMM - O nome do processo. (dd)
    • DISK - O disco que realiza as operações lidas. (vda)
    • I/O - O número de operações lidas realizadas. (16294)
    • Kbytes - A quantidade de Kbytes alcançados pelas operações lidas. (14,440,636)
    • AVGms - O tempo médio de E/S das operações lidas. (3.69)

Para ver mais detalhes, exemplos e opções para biotop, consulte o arquivo /usr/share/bcc/tools/doc/biotop_example.txt.

Para mais informações sobre dd, consulte as páginas do manual dd(1).

Usando xfsslower para expor operações de sistema de arquivo inesperadamente lentas

  1. Executar o programa xfsslower em um terminal: 

    # /usr/share/bcc/tools/xfsslower 1

    O comando acima mede o tempo que o sistema de arquivos XFS gasta em operações de leitura, escrita, abertura ou sincronização (fsync). O argumento 1 garante que o programa mostra apenas as operações que são mais lentas do que 1 ms.

    Nota

    Quando nenhum argumento é fornecido, xfsslower por padrão exibe operações mais lentas do que 10 ms.

  2. Em outro terminal executar, por exemplo, o seguinte: 

    $ vim text

    O comando acima cria um arquivo de texto no editor vim para iniciar certa interação com o sistema de arquivos XFS.

  3. O terminal rodando xfsslower mostra algo semelhante ao salvar o arquivo da etapa anterior: 

    TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
...

    Cada linha acima representa uma operação no sistema de arquivo, que levou mais tempo do que um determinado limite. xfsslower é bom em expor possíveis problemas no sistema de arquivo, que podem tomar a forma de operações inesperadamente lentas.

    A saída xfsslower exibe os seguintes campos:

    • COMM - O nome do processo. (b’bash')

    • T - O tipo de operação. (R)

      • Read
      • Writo
      • Sync
    • OFF_KB - O arquivo compensado em KB. (0)
    • FILENAME - O arquivo sendo lido, escrito, ou sincronizado.

Para ver mais detalhes, exemplos e opções para xfsslower, consulte o arquivo /usr/share/bcc/tools/doc/xfsslower_example.txt.

Para mais informações sobre fsync, consulte as páginas do manual fsync(2).

Capítulo 11. Aumentar a segurança com o subsistema de integridade do kernel

Você pode aumentar a proteção de seu sistema utilizando componentes do subsistema de integridade do kernel. As seções seguintes introduzem os componentes relevantes e fornecem orientações sobre sua configuração.

11.1. O subsistema de integridade do kernel

O subsistema de integridade é uma parte do núcleo que é responsável pela manutenção da integridade geral dos dados do sistema. Este subsistema ajuda a manter o estado de um determinado sistema o mesmo desde o momento em que foi construído, evitando assim modificações indesejáveis em arquivos específicos do sistema por parte dos usuários.

O subsistema de integridade do núcleo é composto por dois componentes principais:

Arquitetura de Medição de Integridade (IMA)
  • Mede o conteúdo dos arquivos sempre que ele é executado ou aberto. Os usuários podem mudar este comportamento aplicando políticas personalizadas.
  • Coloca os valores medidos dentro do espaço de memória do núcleo, evitando assim qualquer modificação por parte dos usuários do sistema.
  • Permite que as partes locais e remotas verifiquem os valores medidos.
Módulo de Verificação Estendida (EVM)
  • Protege os atributos estendidos dos arquivos (também conhecidos como xattr) que estão relacionados à segurança do sistema, como as medidas IMA e os atributos SELinux, através da criptografia de seus valores correspondentes.

Tanto a IMA quanto a EVM também contêm numerosas extensões de recursos que trazem funcionalidade adicional. Por exemplo, a IMA:

IMA-Avaliação
  • Fornece validação local do conteúdo do arquivo atual em relação aos valores previamente armazenados no arquivo de medição dentro da memória do kernel. Esta extensão proíbe qualquer operação a ser realizada sobre um arquivo específico, caso a medida atual e a anterior não coincidam.
Assinaturas Digitais EVM
  • Permite que as assinaturas digitais sejam utilizadas através de chaves criptográficas armazenadas no chaveiro do kernel.
Nota

As extensões das características se complementam, mas é possível configurá-las e utilizá-las independentemente umas das outras.

O subsistema de integridade do kernel pode aproveitar o Módulo de Plataforma Confiável (TPM) para endurecer ainda mais a segurança do sistema. O TPM é uma especificação do Trusted Computing Group (TCG) para funções criptográficas importantes. Os TPMs são normalmente construídos como hardware dedicado que é anexado à placa-mãe da plataforma e evita ataques baseados em software, fornecendo funções criptográficas a partir de uma área protegida e à prova de adulteração do chip de hardware. Algumas das características do TPM são:

  • Gerador de números aleatórios
  • Gerador e armazenamento seguro para chaves criptográficas
  • Gerador Hashing
  • Atestado remoto

Recursos adicionais

11.2. Arquitetura de medição de integridade

A Arquitetura de Medição de Integridade (IMA) é um componente do subsistema de integridade do kernel. A IMA tem como objetivo manter o conteúdo dos arquivos locais. Especificamente, a IMA mede, armazena e avalia os hashes dos arquivos antes que eles sejam acessados, o que impede a leitura e execução de dados não confiáveis. Desta forma, a IMA aumenta a segurança do sistema.

11.3. Módulo de verificação ampliado

O Módulo de Verificação Estendida (EVM) é um componente do subsistema de integridade do kernel, que monitora mudanças nos atributos estendidos dos arquivos (xattr). Muitas tecnologias orientadas à segurança, incluindo a Arquitetura de Medição de Integridade (IMA), armazenam informações de arquivos sensíveis, tais como hashes de conteúdo, nos atributos estendidos. O EVM cria outro hash a partir destes atributos estendidos e de uma chave especial, que é carregada no momento da inicialização. O hash resultante é validado toda vez que o atributo estendido é utilizado. Por exemplo, quando a IMA avalia o arquivo.

A RHEL 8 aceita a chave especial criptografada sob o chaveiro evm-key. A chave foi criada por um master key mantido nos chaveiros do kernel.

11.4. Chaves confiáveis e criptografadas

A seção seguinte apresenta chaves confiáveis e criptografadas como uma parte importante do aumento da segurança do sistema.

Trusted e encrypted keys são chaves simétricas de comprimento variável geradas pelo kernel que utilizam o serviço de chaveiro do kernel. O fato de este tipo de chaves nunca aparecer no espaço do usuário de forma não criptografada significa que sua integridade pode ser verificada, o que por sua vez significa que elas podem ser usadas, por exemplo, pelo módulo de verificação estendida (EVM) para verificar e confirmar a integridade de um sistema em execução. Os programas em nível de usuário só podem acessar as chaves sob a forma de criptografia blobs.

As chaves confiáveis precisam de um componente de hardware: o chip Trusted Platform Module (TPM), que é usado para criar e criptografar (selar) as chaves. O TPM sela as chaves usando uma chave RSA de 2048 bits chamada storage root key (SRK).

Nota

Para usar uma especificação TPM 1.2, habilite-a e ative-a através de um ajuste no firmware da máquina ou usando o comando tpm_setactive do pacote tpm-tools de utilidades. Também é necessário instalar a pilha de software TrouSers e executar o daemon tcsd para se comunicar com o TPM (hardware dedicado). O daemon tcsd faz parte da suíte TrouSers, que está disponível através do pacote trousers. O TPM 2.0, mais recente e retroativo, usa uma pilha de software diferente, onde os utilitários tpm2-tools ou ibm-tss fornecem acesso ao hardware dedicado.

Além disso, o usuário pode selar as chaves confiáveis com um conjunto específico dos valores TPM's platform configuration register (PCR). A PCR contém um conjunto de valores de gerenciamento de integridade que refletem o firmware, o carregador de inicialização e o sistema operacional. Isto significa que as chaves seladas por PCR só podem ser descriptografadas pelo TPM no mesmo sistema em que foram criptografadas. Entretanto, uma vez que uma chave confiável selada PCR é carregada (adicionada a um chaveiro), e assim seus valores PCR associados são verificados, ela pode ser atualizada com novos (ou futuros) valores PCR, de modo que um novo kernel, por exemplo, possa ser inicializado. Uma única chave também pode ser salva como múltiplos blobs, cada um com diferentes valores de PCR.

As chaves criptografadas não requerem um TPM, pois utilizam o kernel Advanced Encryption Standard (AES), o que as torna mais rápidas do que chaves confiáveis. As chaves criptografadas são criadas usando números aleatórios gerados pelo kernel e criptografadas por um master key quando são exportadas para blobs de espaço do usuário. A chave mestra é uma chave confiável ou uma chave do usuário. Se a chave mestra não for confiável, a chave criptografada é apenas tão segura quanto a chave do usuário usada para criptografá-la.

11.4.1. Trabalhando com chaves confiáveis

A seção seguinte descreve como criar, exportar, carregar ou atualizar chaves confiáveis com o utilitário keyctl para melhorar a segurança do sistema.

Pré-requisitos

Procedimento

  1. Para criar uma chave de confiança usando um TPM, execute: 

    # keyctl add trusted <name> "new <key_length> [options]" <key_ring>

    • Com base na sintaxe, construa um comando de exemplo como se segue: 

      # keyctl add trusted kmk "new 32" @u
642500861

      O comando cria uma chave de confiança chamada kmk com o comprimento de 32 bytes (256 bits) e a coloca no chaveiro do usuário (@u). As chaves podem ter um comprimento de 32 a 128 bytes (256 a 1024 bits).

  2. Para listar a estrutura atual dos chaveiros do kernel: 

    # keyctl show
Session Keyring
       -3 --alswrv    500   500  keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

  3. Para exportar a chave para um blob de espaço do usuário, execute: 

    # keyctl pipe 642500861 > kmk.blob

    O comando utiliza o subcomando pipe e o número de série de kmk.

  4. Para carregar a chave confiável do blob de espaço do usuário, use o sub-comando add com o blob como argumento: 

    # keyctl add trusted kmk "load `cat kmk.blob`" @u
268728824

  5. Criar chaves criptografadas seguras com base na chave de confiança selada por TPM: 

    # keyctl add encrypted <name> "new [format] <key_type>:<primary_key_name> <keylength>" <key_ring>

    • Com base na sintaxe, gerar uma chave criptografada utilizando a chave de confiança já criada: 

      # keyctl add encrypted encr-key "new trusted:kmk 32" @u
159771175

      O comando utiliza a chave de confiança selada TPM (kmk), produzida na etapa anterior, como um primary key para a geração de chaves criptografadas.

Recursos adicionais

11.4.2. Trabalhando com chaves criptografadas

A seção seguinte descreve o gerenciamento de chaves criptografadas para melhorar a segurança do sistema em sistemas onde um Módulo de Plataforma Confiável (TPM) não está disponível.

Pré-requisitos

Procedimento

  1. Use uma seqüência aleatória de números para gerar uma chave de usuário: 

    # keyctl add user kmk-user “dd if=/dev/urandom bs=1 count=32 2>/dev/null” @u
427069434

    O comando gera uma chave de usuário chamada kmk-user que atua como um primary key e é usada para selar as chaves criptografadas reais.

  2. Gerar uma chave criptografada usando a chave primária da etapa anterior: 

    # keyctl add encrypted encr-key "new user:kmk-user 32" @u
1012412758

  3. Opcionalmente, liste todas as chaves no chaveiro do usuário especificado: 

    # keyctl list @u
2 keys in keyring:
427069434: --alswrv  1000  1000 user: kmk-user
1012412758: --alswrv  1000  1000 encrypted: encr-key
Importante

Tenha em mente que as chaves criptografadas que não são seladas por uma chave primária confiável são apenas tão seguras quanto a chave primária do usuário (chave de número aleatório) que foi usada para criptografá-las. Portanto, a chave primária do usuário deve ser carregada com a maior segurança possível e de preferência cedo durante o processo de inicialização.

Recursos adicionais

  • Para informações detalhadas sobre o uso de keyctl, consulte a página do manual keyctl(1).
  • Para mais informações sobre o serviço de chaveiro do kernel, veja a documentação do kernel a montante.

11.5. Possibilitando a arquitetura de medição de integridade e módulo de verificação ampliado

A arquitetura de medição de integridade (IMA) e o módulo de verificação estendida (EVM) pertencem ao subsistema de integridade do núcleo e aumentam a segurança do sistema de várias maneiras. A seção seguinte descreve como habilitar e configurar a IMA e EVM para melhorar a segurança do sistema operacional.

Pré-requisitos

  • Verifique se o sistema de arquivos securityfs está montado no diretório /sys/kernel/security/ e se o diretório /sys/kernel/security/integrity/ima/ existe. 

    # mount
…​
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
…​

  • Verifique se o gerente de serviços systemd já está remendado para apoiar a IMA e a EVM no momento da inicialização: 

    # dmesg | grep -i -e EVM -e IMA
[    0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
[    0.000000] kvm-clock: cpu 0, msr 23601001, primary cpu clock
[    0.000000] Using crashkernel=auto, the size chosen is a best effort estimation.
[    0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
[    0.911527] ima: No TPM chip found, activating TPM-bypass!
[    0.911538] ima: Allocated hash algorithm: sha1
[    0.911580] evm: Initialising EVM extended attributes:
[    0.911581] evm: security.selinux
[    0.911581] evm: security.ima
[    0.911582] evm: security.capability
[    0.911582] evm: HMAC attrs: 0x1
[    1.715151] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)
[    3.824198] fbcon: qxldrmfb (fb0) is primary device
[    4.673457] PM: Image not found (code -22)
[    6.549966] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)

Procedimento

  1. Adicione os seguintes parâmetros de linha de comando do kernel: 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

    O comando permite a IMA e EVM no modo fix para a entrada de inicialização atual e permite aos usuários reunir e atualizar as medidas da IMA.

    O parâmetro de linha de comando do kernel ima_policy=appraise_tcb garante que o kernel utilize a política de medição padrão da Trusted Computing Base (TCB) e a etapa de avaliação. A parte de avaliação proíbe o acesso a arquivos, cujas medidas anteriores e atuais não correspondem.

  2. Reiniciar para que as mudanças entrem em vigor.

  3. Opcionalmente, verificar se os parâmetros foram adicionados à linha de comando do kernel: 

    # cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix

  4. Criar uma chave mestra do núcleo para proteger a chave EVM: 

    # keyctl add user kmk dd if=/dev/urandom bs=1 count=32 2> /dev/null @u
748544121

    A chave-mestra do kernel (kmk) é mantida inteiramente na memória de espaço do kernel. O valor de 32 bytes da chave-mestra do kernel kmk é gerado a partir de bytes aleatórios do arquivo /dev/urandom e colocado no chaveiro do usuário (@u). O número de série da chave está na segunda linha da saída anterior.

  5. Criar uma chave EVM criptografada com base na chave kmk: 

    # keyctl add encrypted evm-key "new user:kmk 64" @u
641780271

    O comando usa kmk para gerar e criptografar uma chave de usuário de 64 bytes (chamada evm-key) e a coloca no chaveiro do usuário (@u). O número de série da chave está na segunda linha da saída anterior.

    Importante

    É necessário nomear a chave do usuário como evm-key porque esse é o nome que o subsistema EVM está esperando e com o qual está trabalhando.

  6. Criar um diretório para chaves exportadas: 

    # mkdir -p /etc/keys/

  7. Procure a chave kmk e exporte seu valor para um arquivo: 

    # keyctl pipe keyctl search @u user kmk > /etc/keys/kmk *

    O comando coloca o valor não criptografado da chave-mestra do kernel (kmk) em um arquivo de localização previamente definida (/etc/keys/).

  8. Procure a chave do usuário evm-key e exporte seu valor para um arquivo: 

    # keyctl pipe keyctl search @u encrypted evm-key > /etc/keys/evm-key

    O comando coloca o valor codificado do usuário evm-key em um arquivo de localização arbitrária. O evm-key foi criptografado pela chave-mestra do kernel anteriormente.

  9. Opcionalmente, veja as chaves recém-criadas: 

    # keyctl show
Session Keyring
974575405   --alswrv     0        0      keyring: ses 299489774 --alswrv 0 65534 \ keyring: uid.0 748544121 --alswrv 0 0 \ user: kmk
641780271   --alswrv     0        0           \_ encrypted: evm-key

    Você deve ser capaz de ver um resultado semelhante.

  10. Ativar o EVM: 

    # echo 1 > /sys/kernel/security/evm

  11. Opcionalmente, verificar se a EVM foi inicializada: 

    # dmesg | tail -1
[…​] evm: key initialized

Recursos adicionais

11.6. Coleta de hashes de arquivo com arquitetura de medição de integridade

O primeiro nível de operação da arquitetura de medição de integridade (IMA) é a fase measurement, que permite criar hashes de arquivos e armazená-los como atributos estendidos (xattrs) desses arquivos. A seção seguinte descreve como criar e inspecionar os hashes dos arquivos.

Pré-requisitos

  • Habilitar arquitetura de medição de integridade (IMA) e módulo de verificação estendida (EVM), conforme descrito em Seção 11.5, “Possibilitando a arquitetura de medição de integridade e módulo de verificação ampliado”.

  • Verifique se os pacotes ima-evm-utils, attr, e keyutils já estão instalados: 

    # yum install ima-evm-utils attr keyutils
Updating Subscription Management repositories.
This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.
Last metadata expiration check: 0:58:22 ago on Fri 14 Feb 2020 09:58:23 AM CET.
Package ima-evm-utils-1.1-5.el8.x86_64 is already installed.
Package attr-2.4.48-3.el8.x86_64 is already installed.
Package keyutils-1.5.10-7.el8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Procedimento

  1. Criar um arquivo de teste: 

    # echo <Test_text> > test_file

    A IMA e a EVM garantem que ao arquivo de exemplo test_file sejam atribuídos valores de hash, que são armazenados como seus atributos estendidos.

  2. Inspecione os atributos estendidos do arquivo: 

    # getfattr -m . -d test_file
# file: test_file
security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD
security.selinux="unconfined_u:object_r:admin_home_t:s0"

    O exemplo anterior mostra atributos estendidos relacionados ao SELinux e aos valores de hash da IMA e EVM. O EVM adiciona ativamente um atributo estendido security.evm e detecta qualquer adulteração offline em xattrs de outros arquivos como security.ima que estão diretamente relacionados à integridade do conteúdo dos arquivos. O valor do campo security.evm está em Hash-based Message Authentication Code (HMAC-SHA1), que foi gerado com a chave de usuário evm-key.

Recursos adicionais

Capítulo 12. Utilização de funções possíveis para configurar permanentemente os parâmetros do kernel

Como um usuário experiente com bom conhecimento do Red Hat Ansible Engine, você pode usar a função kernel_settings para configurar os parâmetros do kernel em múltiplos clientes ao mesmo tempo. Esta solução:

  • Fornece uma interface amigável com ajuste de entrada eficiente.
  • Mantém todos os parâmetros de kernel pretendidos em um só lugar.

Após executar a função kernel_settings a partir da máquina de controle, os parâmetros do núcleo são aplicados imediatamente aos sistemas gerenciados e persistem em todas as reinicializações.

12.1. Introdução ao papel das configurações do kernel

As funções do Sistema RHEL são uma coleção de funções e módulos da Plataforma de Automação Possível que fornecem uma interface de configuração consistente para gerenciar remotamente vários sistemas.

As funções do sistema RHEL foram introduzidas para configurações automatizadas do kernel usando a função do sistema kernel_settings. O pacote rhel-system-roles contém esta função do sistema, e também a documentação de referência.

Para aplicar os parâmetros do kernel em um ou mais sistemas de forma automatizada, use a função kernel_settings com uma ou mais de suas variáveis de papel de sua escolha em um playbook. Um playbook é uma lista de uma ou mais peças que são legíveis por humanos, e são escritas no formato YAML.

Você pode usar um arquivo de inventário para definir um conjunto de sistemas que você deseja que o Ansible Engine configure de acordo com o playbook.

Com a função kernel_settings você pode configurar:

  • Os parâmetros do kernel usando a variável de função kernel_settings_sysctl
  • Vários subsistemas de kernel, dispositivos de hardware e drivers de dispositivos usando a variável de função kernel_settings_sysfs
  • A afinidade da CPU para o gerente de serviços systemd e processa-a forquilha usando a variável de função kernel_settings_systemd_cpu_affinity
  • O subsistema de memória do kernel hugepages transparentes usando as variáveis de função kernel_settings_transparent_hugepages e kernel_settings_transparent_hugepages_defrag

Recursos adicionais

  • Para uma referência detalhada sobre as variáveis de papel kernel_settings e para os exemplos de playbooks, instale o pacote rhel-system-roles, e veja os arquivos README.md e README.html no diretório /usr/share/doc/rhel-system-roles/kernel_settings/.
  • Para mais informações sobre playbooks, consulte Trabalhando com playbooks na documentação Ansible.
  • Para mais informações sobre como criar e usar inventários, veja Como construir seu inventário em Documentação possível.

12.2. Aplicação de parâmetros selecionados do kernel usando a função de configuração do kernel

Siga estas etapas para preparar e aplicar um livro de exercícios possível para configurar remotamente os parâmetros do kernel com efeito persistente em múltiplos sistemas operacionais gerenciados.

Pré-requisitos

  • Sua assinatura do Red Hat Ansible Engine está anexada ao sistema, também chamado control machine, a partir do qual você deseja executar o papel kernel_settings. Veja o artigo Como faço o download e instalo o Red Hat Ansible Engine para mais informações.
  • O possível repositório do motor está habilitado na máquina de controle.

  • O Motor Possível é instalado na máquina de controle.

    Nota

    Você não precisa ter o Ansible Engine instalado nos sistemas, também chamado managed hosts, onde você deseja configurar os parâmetros do kernel.

  • O pacote rhel-system-roles está instalado na máquina de controle.
  • Um inventário de hosts gerenciados está presente na máquina de controle e o Ansible Engine é capaz de se conectar a eles.

Procedimento

  1. Opcionalmente, revisar o arquivo inventory para fins de ilustração: 

    #  cat /home/jdoe/<ansible_project_name>/inventory
[testingservers]
pdoe@192.168.122.98
fdoe@192.168.122.226

[db-servers]
db1.example.com
db2.example.com

[webservers]
web1.example.com
web2.example.com
192.0.2.42

    O arquivo define o grupo [testingservers] e outros grupos. Ele permite rodar o Ansible Engine de forma mais eficaz contra uma coleção específica de sistemas.

  2. Criar um arquivo de configuração para definir padrões e escalonamento de privilégios para operações de Motores Ansíveis.

    1. Criar um novo arquivo YAML e abri-lo em um editor de texto, por exemplo: 

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg

    2. Insira o seguinte conteúdo no arquivo: 

      [defaults]
inventory = ./inventory

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = true

      A seção [defaults] especifica um caminho para o arquivo do inventário de anfitriões gerenciados. A seção [privilege_escalation] define que os privilégios do usuário sejam transferidos para root nos hosts gerenciados especificados. Isto é necessário para uma configuração bem sucedida dos parâmetros do kernel. Quando o Ansible playbook for executado, você será solicitado a fornecer a senha do usuário. O usuário muda automaticamente para root por meio de sudo após conectar-se a um host gerenciado.

  3. Criar um caderno de atividades que utilize o papel kernel_settings.

    1. Criar um novo arquivo YAML e abri-lo em um editor de texto, por exemplo: 

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      Este arquivo representa um playbook e normalmente contém uma lista ordenada de tarefas, também chamada plays, que são executadas contra hosts gerenciados específicos selecionados a partir de seu arquivo inventory.

    2. Insira o seguinte conteúdo no arquivo: 

      ---
- name: Configure kernel settings
  hosts: testingservers

  vars:
    kernel_settings_sysctl:
      - name: fs.file-max
        value: 400000
      - name: kernel.threads-max
        value: 65536
    kernel_settings_sysfs:
      - name: /sys/class/net/lo/mtu
        value: 65000
    kernel_settings_transparent_hugepages: madvise

  roles:
    - linux-system-roles.kernel_settings

      A chave name é opcional. Ela associa uma corda arbitrária com a peça como um rótulo e identifica para que serve a peça. A chave hosts na peça especifica os anfitriões contra os quais a peça é encenada. O valor ou valores para esta chave podem ser fornecidos como nomes individuais de anfitriões gerenciados ou como grupos de anfitriões, conforme definido no arquivo inventory.

      A seção vars representa uma lista de variáveis contendo nomes de parâmetros e valores de kernel selecionados para os quais eles têm que ser definidos.

      A chave roles especifica qual papel do sistema irá configurar os parâmetros e valores mencionados na seção vars.

      Nota

      Você pode modificar os parâmetros do kernel e seus valores no playbook para atender às suas necessidades.

  4. Opcionalmente, verifique se a sintaxe em sua peça está correta. 

    #  ansible-playbook --syntax-check kernel-roles.yml

playbook: kernel-roles.yml

    Este exemplo mostra a verificação bem sucedida de um livro de brincadeiras.

  5. Execute seu livro de brincadeiras. 

    #  ansible-playbook kernel-roles.yml
BECOME password:

PLAY [Configure kernel settings]  ... PLAY RECAP **
fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

    Antes do Ansible Engine executar seu playbook, você será solicitado a obter sua senha e para que um usuário em hosts gerenciados possa ser trocado para root, o que é necessário para configurar os parâmetros do kernel.

    A seção recapitulativa mostra que a peça terminou com sucesso (failed=0) para todos os anfitriões gerenciados, e que 4 parâmetros do kernel foram aplicados (changed=4).

  6. Reinicie seus anfitriões gerenciados e verifique os parâmetros do núcleo afetado para verificar se as mudanças foram aplicadas e persistem em todas as reinicializações.

Recursos adicionais

  • Para mais informações sobre as funções do Sistema RHEL, consulte Introdução às funções do Sistema RHEL.
  • Para mais informações sobre todas as variáveis atualmente suportadas em kernel_settings, consulte os arquivos README.html e README.md no diretório /usr/share/doc/rhel-system-roles/kernel_settings/.
  • Para mais detalhes sobre Inventários Ansíveis, consulte Trabalhando com Inventário em Documentação Possível.
  • Para obter mais detalhes sobre os arquivos de configuração de Ansible, consulte Configuring Ansible in Ansible documentation.
  • Para mais detalhes sobre Playbooks Ansíveis, consulte Trabalhando com Playbooks na documentação Ansible.
  • Para obter mais detalhes sobre Variáveis Ansíveis, consulte Utilização de Variáveis em Documentação Possível.
  • Para mais detalhes sobre os papéis possíveis, consulte Papéis em documentação possível.