Core dump (Português) - ArchWiki

# Core dump (Português)

From ArchWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Status de tradução: Esse artigo é uma tradução de Core dump. Data da última tradução: 2020-09-14. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Um despejo de núcleo (core dump) é um arquivo que contém o espaço de endereço de um processo (memória) quando o processo termina inesperadamente. Despejos de núcleo podem ser produzidos sob demanda (como por um depurador), ou automaticamente após o encerramento. Despejos de núcleos são acionados pelo kernel em resposta a travamentos do programa e podem ser passados para um programa auxiliar (como systemd-coredump) para processamento posterior. Um despejo de núcleo não é normalmente usado por um usuário médio, mas pode ser repassado aos desenvolvedores mediante solicitação, onde pode ser inestimável como um instantâneo post-mortem do estado do programa no momento da falha, especialmente se a falha for difícil de reproduzir de forma confiável.

## Desabilitando automaticamente despejos de núcleo

Os usuários podem desejar desativar os despejos de núcleo automáticos por uma série de razões:

- Desempenho: gerar despejos de núcleo para processos com muita memória pode desperdiçar recursos do sistema e atrasar a limpeza da memória.
- Espaço em disco: os despejos de núcleo de processos com muita memória podem consumir espaço em disco igual, senão maior, que a área de cobertura da memória do processo se não for compactado.
- Segurança: despejos de núcleo, embora normalmente legíveis apenas pelo root, podem conter dados confidenciais (como senhas ou chaves criptográficas), que são gravados no disco após um travamento.

### Usando sysctl

sysctl pode ser usado para definir o `kernel.core_pattern` para nada para desabilitar o tratamento de despejo de núcleo. Crie este arquivo[1]:

    /etc/sysctl.d/50-coredump.conf

    kernel.core_pattern=|/bin/false

Para aplicar a configuração imediatamente, use `sysctl`:

    # sysctl -p /etc/sysctl.d/50-coredump.conf

### Usando systemd

O comportamento padrão do systemd é gerar despejos de núcleo para todos os processos em `/var/lib/systemd/coredump`. Este comportamento pode ser substituído criando um trecho de código de configuração no diretório `/etc/systemd/coredump.conf.d/` com o seguinte conteúdo[2][3]:

    /etc/systemd/coredump.conf.d/custom.conf

    [Coredump]
    Storage=none

Nota: Não esqueça de incluir o nome de seção `[Coredump]`, do contrário esta opção será ignorado: `systemd-coredump[1728]: [/etc/systemd/coredump.conf.d/custom.conf:1] Assignment outside of section. Ignoring.`

Em seguida, recarregue a configuração do systemd.

    # systemctl daemon-reload

Este método sozinho geralmente é suficiente para desabilitar os despejos de núcleo do espaço do usuário, contanto que nenhum outro programa habilite os despejos de núcleo automáticos no sistema, mas o despejo de núcleo ainda é gerado na memória e na execução de systemd-coredump.

### Usando limites do PAM

O tamanho máximo de despejos de núcleo para usuários autenticados via PAM é imposto por limits.conf. Definir como zero desabilita os despejos com núcleo inteiramente. [4]

    /etc/security/limits.conf

    * hard core 0

### Usando ulimit

Shells de linha de comando como bash ou zsh fornecem um comando embutido ulimit que pode ser usado para relatar ou definir limites de recursos do shell e os processos iniciados pelo shell. Veja bash(1) § SHELL BUILTIN COMMANDS ou zshbuiltins(1) para detalhes.

Para desabilitar despejos de núcleo na shell atual:

    $ ulimit -c 0

## Fazendo um despejo de núcleo

Para gerar um despejo de núcleo de um processo arbitrário, primeiro instale o pacote gdb. Em seguida, encontre o PID do processo em execução, por exemplo com pgrep:

    $ pgrep -f firefox

    2071 firefox

Anexe ao processo:

    $ gdb -p 2071

Então, no prompt `(gdb)`:

    (gdb) generate-core-file
    Saved corefile core.2071
    (gdb) quit

Agora, você tem um arquivo de despejo de núcleo chamado `core.2071`.

### Aonde eles vão?

O sysctl `kernel.core_pattern` decide aonde os despejos de núcleo automáticos vão. Por padrão, despejos de núcleo são enviados para systemd-coredump que pode ser configurado em `/etc/systemd/coredump.conf`. Por padrão, todos os despejos de núcleo são armazenados em `/var/lib/systemd/coredump` (por causa de `Storage=external`) e eles são compactados com `lz4` (por causa de `Compress=yes`). Adicionalmente, vários limites de tamanho para o armazenamento podem ser configurados.

Nota: O valor padrão para `kernel.core_pattern` é definido em `/usr/lib/sysctl.d/50-coredump.conf`. Este arquivo pode ser mascarado ou substituído para usar uma configuração diferente segundo as regras normais de sysctl.d(5).

Para obter um despejo de núcleo do journal, veja coredumpctl(1).

## Examinando um despejo de núcleo

Use coredumpctl para localizar um despejo correspondente:

    # coredumpctl list

Você precisa identificar exclusivamente o despejo relevante. Isso é possível especificando um `PID`, nome do executável, caminho para o executável ou um predicado journalctl (consulte coredumpctl(1) e journalctl(1) para detalhes) Para ver detalhes dos despejo de núcleo:

    # coredumpctl info correspondência

Preste atenção à linha "Signal", que ajuda a identificar a causa do travamento. Para uma análise mais profunda, você pode examinar o backtrace usando gdb:

    # coredumpctl gdb correspondência

Quando gdb é iniciado, use o comando `bt` para imprimir o backtrace:

    (gdb) bt

Veja Depuração - Obtendo Rastros se símbolos de depuração forem solicitados, mas não encontrados.

## Limpeza de arquivos de despejo de núcleo

Os arquivos de despejo de núcleo armazenados em `/var/lib/systemd/coredump/` serão limpados automaticamente por `systemd-tmpfiles --clean`, que é acionado diariamente com `systemd-tmpfiles-clean.timer`. Despejos de núcleo são configurados para persistir por pelo menos 3 dias, veja `systemd-tmpfiles --cat-config`.

## Veja também

- american fuzzy lop - Uma ferramenta para testes automatizados do kernel e de programas
- Filesystem fuzzing - Artigo da LWN sobre teste de sistemas de arquivos em busca de bugs

Categories:

- Development (Português)
- Security (Português)