Tutorial de Linux / Entendendo os Serviços, Inicialização e Logs do systemd

Em um sistema Linux que utiliza systemd, a inicialização ocorre do firmware e do carregador de boot para o kernel; então o systemd ativa serviços e outras unidades. Para investigar um serviço, use systemctl para verificar tanto seu estado atual quanto sua habilitação para inicialização, e use journalctl para ler os logs da mesma inicialização. Estar ativo agora e estar habilitado para inicialização são condições diferentes.

Esta é uma introdução ao estado de serviços, à inicialização e à habilitação. A investigação de falhas baseada em logs, em inglês combina vários tipos de evidências para identificar a causa.

Exercícios de configuração do sistema usam uma VM convencional Ubuntu 26.04 LTS ou Rocky Linux 9 como o ambiente de referência. Contêineres, WSL e outras versões podem diferir na configuração de serviços e pacotes. Prepare a recuperação pelo console e registre suas versões usando a aula de preparação da máquina virtual, em inglês.

Entenda os principais estágios de inicialização

Um PC ou servidor típico começa com o firmware inicializando o hardware e localizando um carregador de inicialização. O carregador de inicialização carrega o kernel e o ambiente inicial necessário. O kernel prepara os dispositivos, a memória e a execução de processos, após o que um sistema de inicialização gerencia os serviços do espaço do usuário. Esta lição se aplica onde systemd é PID 1. Um contêiner ou distribuição que use outro sistema init pode requerer comandos e explicações diferentes.

ps -p 1 -o pid,comm,args
systemctl get-default

Use COMMAND ou ARGS no primeiro resultado para verificar se o PID 1 é systemd. Isso pode diferir em um contêiner ou ambiente especializado. O segundo comando mostra o alvo padrão. Por exemplo, multi-user.target comumente representa um objetivo multiusuário não gráfico; graphical.target pode representar um objetivo gráfico. Um alvo agrupa unidades. Isso não significa que todos os serviços iniciam um após o outro em uma única sequência.

Entenda as unidades e dependências do systemd

systemd representa objetos gerenciados como unidades. Uma unidade .service gerencia um serviço; uma .target agrupa unidades em um objetivo; uma .socket pode fornecer ativação por soquete; e uma .timer agenda uma ação. O pacote de um serviço e a unidade devem realmente estar instalados. Não adivinhe o nome de uma unidade e a inicie ou pare em uma máquina de produção.

A ordem de inicialização segue as dependências das unidades e regras de ordenação, não uma simples ordem numérica. Uma regra de ordenação como After= não cria, por si só, uma dependência de necessidade como Requires= ou Wants=. Algumas unidades são executadas em paralelo, portanto, a ordem da lista exibida sozinha não pode estabelecer a causa de uma inicialização lenta.

systemctl list-units --type=service --state=running
systemctl --failed

O primeiro comando lista as unidades de serviço em execução carregadas; o segundo lista as unidades em estado de falha. Uma lista de falhas vazia não prova que uma aplicação está respondendo corretamente. Seu endpoint, porta ou próprios logs também podem precisar ser verificados.

Separar o estado atual da habilitação no boot

active indica se uma unidade está ativa agora. enabled normalmente significa que um link de instalação foi criado para que ela possa iniciar com um alvo no boot. Um serviço pode ser active mas disabled, ou enabled mas em estado de falha no momento. Uma unidade static pode não ter uma regra de instalação para habilitação direta, mas ainda assim funcionar porque outra unidade a requer ou a ativa.

NAME.service na tabela é um espaço reservado: substitua-o por uma unidade que exista em seu sistema. Parar uma unidade crítica, como o serviço SSH usado para acesso remoto, pode desconectá-lo. Verifique o impacto e uma rota de recuperação antes de alterar qualquer serviço de produção.

Inspecione um serviço com comandos somente leitura

systemd-journald.service é comum em sistemas systemd, embora uma imagem mínima ou especializada possa se comportar de maneira diferente. Esses comandos apenas inspecionam o estado.

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status pode mostrar informações de carga, estado atual, processos e entradas recentes do journal. is-active pode relatar active, inactive ou failed e pode retornar um status de saída diferente de zero quando inativo. is-enabled pode relatar enabled, disabled ou static, entre outros resultados. Não trate static como um erro por si só.

Comandos para conhecer antes de alterar um serviço

Os exemplos com barras na tabela comparam duas operações: escolha start ou stop, por exemplo, e não digite a barra como parte do comando. Quando uma alteração é necessária, start e stop afetam o estado atual, enquanto enable e disable afetam a ativação automática. restart interrompe e inicia um serviço e pode interromper conexões ou trabalhos. reload solicita a um serviço que releia a configuração apenas se ele suportar essa operação; o efeito é específico do serviço. enable --now solicita tanto a habilitação quanto o início imediato.

Após criar ou editar um arquivo de unidade, daemon-reload pode ser necessário para que o systemd releia as definições de unidade. Isso difere de restart, que reinicia um processo de aplicativo, e do próprio reload de um serviço, que pode reler a configuração do aplicativo. Planeje backups e uma janela de manutenção antes de alterar a configuração de unidade ou de aplicativo em produção.

Leia os logs da inicialização atual com journalctl

O journal do systemd pode coletar mensagens de serviços, do kernel e de outras fontes. -b seleciona a inicialização atual, -u seleciona uma unidade e -n 30 solicita as 30 entradas mais recentes. Sem permissões adequadas, você pode ver apenas algumas mensagens; um administrador autorizado pode inspecionar o restante.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

O primeiro comando mostra as entradas recentes dessa unidade durante esta inicialização. O segundo mostra as entradas recentes com prioridade de aviso ou superior. Um aviso não é necessariamente a causa de uma falha; considere seu momento e as mensagens ao redor. Se --list-boots não mostrar uma inicialização anterior, a retenção ou a política de armazenamento do journal pode significar que seus logs estão indisponíveis. Verifique se uma inicialização anterior está registrada antes de tentar diagnosticá-la.

Uma sequência para diagnosticar um serviço que não inicia

1. Confirme o nome exato da unidade e se seu pacote está instalado. Não manipule uma unidade com nome semelhante por tentativa e erro.
2. Use systemctl status para verificar o estado de carregamento, estado atual, resumo de falhas e mensagens recentes.
3. Leia mais contexto do mesmo boot com journalctl -b -u. Procure evidências de erro de configuração, permissões, conflito de porta ou dependência falha.
4. Inspecione a configuração relevante, recursos e dependências; faça um backup antes de alterá-los. Não enfraqueça permissões de forma ampla baseado em uma linha de log.
5. Após corrigir a causa, execute apenas a ação necessária em um momento aceitável, e então verifique is-active e a resposta real do aplicativo.

Para inicialização lenta, systemd-analyze critical-chain pode ajudar a revelar um caminho de inicialização importante. Um tempo individual longo em systemd-analyze blame não prova, por si só, que a unidade atrasou toda a inicialização: ela pode estar esperando outra unidade. Execução paralela e dependências importam; o relatório também não mede o tempo em fila e omite tempos de inicialização de serviços Type=simple.

Referências oficiais

O manual systemctl(1) cobre status e alterações em unidades. O manual journalctl(1) documenta inicialização, unidades e filtros de prioridade. O manual systemd.unit(5) descreve unidades e seus relacionamentos de dependência.