Como analisar a inicialização com "systemd-analyze"

1. Verificando se o sistema usa systemd

Antes de começar, confirme qual processo está sendo executado como PID 1:

$ ps -p 1 -o comm=

Em um sistema baseado no systemd, a saída será:

systemd

Confira também a versão instalada:

$ systemd-analyze --version

A saída poderá ser semelhante a:

systemd 257

Os recursos disponíveis podem variar conforme a versão utilizada pela distribuição.

2. Medindo o tempo total da inicialização

A forma mais simples de usar a ferramenta é executar:

$ systemd-analyze

Esse comando equivale a:

$ systemd-analyze time

Uma saída possível seria:

Startup finished in 8.434s (firmware) +
2.106s (loader) +
3.172s (kernel) +
5.894s (userspace) =
19.607s graphical.target reached after 5.641s in userspace.

O resultado divide a inicialização em etapas:

Nem todos os campos aparecem em todas as máquinas. A medição do firmware e do carregador, por exemplo, depende de o equipamento e o carregador fornecerem essas informações ao systemd.

O tempo total também não representa necessariamente o momento em que o computador está completamente ocioso ou em que todos os programas gráficos terminaram de carregar. Ele indica quando o alvo correspondente foi alcançado e as unidades necessárias foram iniciadas.

3. Entendendo a execução paralela

Somar os tempos individuais dos serviços não produz o tempo total da inicialização. O systemd inicia muitas unidades paralelamente.

Considere três serviços:

• serviço-a: 5 segundos
• serviço-b: 4 segundos
• serviço-c: 3 segundos

Se forem iniciados simultaneamente, eles podem acrescentar aproximadamente cinco segundos à inicialização, e não doze.

Esse comportamento é essencial para interpretar corretamente os próximos comandos. Um serviço pode levar vários segundos para iniciar sem estar atrasando o restante do sistema.

4. Identificando as unidades mais demoradas

Execute:

$ systemd-analyze blame

A ferramenta apresenta as unidades ordenadas pelo tempo que levaram para alcançar o estado ativo:

8.341s NetworkManager-wait-online.service
4.227s plymouth-quit-wait.service
2.612s dev-nvme0n1p2.device
1.823s accounts-daemon.service
1.306s systemd-logind.service
 987ms firewalld.service
 614ms systemd-udev-settle.service

As primeiras linhas merecem atenção porque mostram as unidades que permaneceram mais tempo em ativação.

Podemos limitar a saída:

$ systemd-analyze blame | head -20

Para procurar uma unidade específica:

$ systemd-analyze blame | grep NetworkManager

A saída pode incluir diferentes tipos de unidades:

• .service, para serviços;
• .device, para dispositivos;
• .mount, para sistemas de arquivos;
• .socket, para sockets;
• .swap, para espaços de troca;
• .target, para agrupamentos de unidades.

5. Por que o resultado de blame pode enganar

O comando systemd-analyze blame é um bom ponto de partida, mas não deve ser interpretado como uma lista definitiva dos culpados pela lentidão.

Uma unidade pode apresentar um tempo elevado porque:

• estava aguardando outra unidade;
• aguardava a rede ficar disponível;
• esperava um dispositivo;
• foi iniciada paralelamente a outros serviços;
• somente conclui a ativação depois de receber uma resposta externa;
• seu tipo de serviço permite medir a ativação com mais precisão do que outros.

Considere esta linha:

8.341s NetworkManager-wait-online.service

Isso não significa necessariamente que o NetworkManager precisou de mais de oito segundos para funcionar. O serviço NetworkManager-wait-online foi criado para aguardar até que a rede satisfaça determinadas condições. Ele pode estar cumprindo exatamente a função para a qual foi configurado.

Desativá-lo sem investigar as dependências pode prejudicar serviços que realmente precisam de conectividade durante a inicialização.

Também existem serviços que informam ao systemd que foram iniciados antes de concluir todo o trabalho interno. Nesses casos, o tempo apresentado pode parecer muito pequeno.

Use blame para encontrar candidatos à investigação, e não como justificativa automática para desativar unidades.

6. Examinando a cadeia crítica

Para descobrir quais unidades realmente fazem parte do caminho que determina quando o sistema alcança o alvo principal, execute:

$ systemd-analyze critical-chain

Uma saída possível seria:

graphical.target @5.641s
└─multi-user.target @5.640s
 └─NetworkManager-wait-online.service @1.314s +4.325s
  └─NetworkManager.service @623ms +688ms
   └─dbus-broker.service @512ms +108ms
    └─basic.target @498ms
     └─sockets.target @497ms
      └─dbus.socket @496ms

A cadeia é apresentada de trás para frente, começando pelo alvo que foi alcançado.

Os símbolos possuem significados diferentes:

@1.314s

indica o momento, contado desde o início do processo analisado, em que a unidade começou ou se tornou ativa.

Já:

+4.325s

indica quanto tempo a unidade levou para ser ativada.

No exemplo, NetworkManager-wait-online.service começou aproximadamente 1,3 segundo depois do início do espaço de usuário e levou cerca de 4,3 segundos para concluir sua ativação.

7. Analisando a cadeia de uma unidade específica

Também podemos pedir a cadeia crítica de um serviço:

$ systemd-analyze critical-chain sshd.service

Em algumas distribuições, o serviço SSH possui outro nome:

$ systemd-analyze critical-chain ssh.service

Para analisar o gerenciador de rede:

$ systemd-analyze critical-chain NetworkManager.service

Para analisar o alvo gráfico:

$ systemd-analyze critical-chain graphical.target

Se quiser mostrar mais de uma ramificação por unidade, use:

$ systemd-analyze critical-chain --fuzz=1s

O parâmetro informa uma tolerância. Dessa forma, unidades iniciadas em momentos próximos ao da cadeia principal também podem aparecer.

O valor pode ser ajustado:

$ systemd-analyze critical-chain --fuzz=500ms
$ systemd-analyze critical-chain --fuzz=2s

Assim como ocorre com blame, a cadeia crítica precisa ser interpretada com cuidado. Ativação por socket, execução paralela e determinadas dependências podem fazer com que o resultado não represente toda a história.

8. Gerando um gráfico da inicialização

Uma das funções mais úteis do systemd-analyze é a geração de um gráfico em formato SVG:

$ systemd-analyze plot > inicializacao.svg

Abra o arquivo com o navegador:

$ xdg-open inicializacao.svg

Também é possível usar diretamente um navegador:

$ firefox inicializacao.svg

O gráfico apresenta uma linha do tempo com:

• início do kernel;
• inicialização do espaço de usuário;
• momento em que cada unidade começou;
• duração da ativação;
• execução paralela dos serviços;
• ponto em que os principais alvos foram alcançados.

Como o arquivo SVG é vetorial, podemos ampliá-lo sem perda de qualidade. Em sistemas com muitas unidades, o gráfico pode ficar bastante alto, mas continua sendo útil para localizar períodos de espera e sobreposições.

Para incluir detalhes adicionais no gráfico, dependendo da versão instalada:

$ systemd-analyze plot --detailed > inicializacao-detalhada.svg

Confira as opções disponíveis em seu sistema:

$ systemd-analyze plot --help

9. Criando um gráfico de dependências

O plot apresenta uma linha do tempo. Para visualizar relacionamentos entre unidades, podemos usar:

$ systemd-analyze dot

A saída utiliza a linguagem DOT. Para transformá-la em uma imagem, instale o Graphviz e execute:

$ systemd-analyze dot | dot -Tsvg > dependencias.svg

Abra o gráfico:

$ xdg-open dependencias.svg

O diagrama completo pode ser enorme. Por isso, geralmente é melhor limitar a análise a uma unidade:

$ systemd-analyze dot sshd.service | dot -Tsvg > sshd-dependencias.svg

Para visualizar somente as dependências que uma unidade utiliza:

$ systemd-analyze dot \
  --to-pattern='sshd.service' |
  dot -Tsvg > dependencias-do-sshd.svg

Para mostrar as unidades que dependem dela:

$ systemd-analyze dot \
  --from-pattern='sshd.service' |
  dot -Tsvg > dependentes-do-sshd.svg

Os nomes podem variar. Antes, confirme o nome da unidade:

$ systemctl list-unit-files | grep -i ssh

10. Consultando os serviços que falharam

Um computador pode iniciar com tempo aceitável e ainda possuir unidades com erro.

Liste-as:

$ systemctl --failed

A saída poderá ser:

UNIT        LOAD  ACTIVE SUB  DESCRIPTION
backup.service   loaded failed failed Cópia de segurança

Examine o estado da unidade:

$ systemctl status backup.service

Consulte suas mensagens na inicialização atual:

$ journalctl -b -u backup.service

O parâmetro -b limita a consulta ao boot atual.

Para visualizar erros gerais desse boot:

$ journalctl -b -p err

Para incluir mensagens de prioridade warning ou superior:

$ journalctl -b -p warning

Esses comandos complementam o systemd-analyze, pois mostram o motivo pelo qual uma unidade demorou ou falhou.

11. Consultando inicializações anteriores

Por padrão, systemd-analyze trabalha com os dados da inicialização atual. O journalctl, porém, pode ajudar a comparar boots anteriores, desde que o diário seja persistente.

Liste as inicializações registradas:

$ journalctl --list-boots

A saída será semelhante a:

-2 841d... Sat 2026-08-22 08:14:21 -03—Sat 2026-08-22 16:42:10 -03
 -1 a712... Sun 2026-08-23 09:03:41 -03—Sun 2026-08-23 22:08:33 -03
 0 f209... Mon 2026-08-24 07:50:12 -03—Mon 2026-08-24 10:31:02 -03

Consulte as mensagens do boot anterior:

$ journalctl -b -1

Examine uma unidade no boot anterior:

$ journalctl -b -1 -u NetworkManager.service

Mostre os erros daquela inicialização:

$ journalctl -b -1 -p err

Essa comparação é útil quando a lentidão ocorre de forma intermitente.

12. Verificando arquivos de unidades

O systemd-analyze também verifica a sintaxe e algumas relações de dependência dos arquivos de unidades.

Para examinar um serviço personalizado:

$ systemd-analyze verify meu-servico.service

Se o arquivo estiver em um caminho específico:

$ systemd-analyze verify \
  /etc/systemd/system/meu-servico.service

Um erro poderá ser apresentado assim:

 Unknown key 'Restar' in section [Service]

Nesse caso, provavelmente foi escrito:

ini
Restar=always

em vez de:

ini
Restart=always

Também podem aparecer avisos sobre:

• diretivas desconhecidas;
• seções incorretas;
• dependências inexistentes;
• comandos não encontrados;
• arquivos auxiliares ausentes;
• relações de ordenação problemáticas.

Depois de modificar uma unidade instalada, recarregue a configuração:

$ sudo systemctl daemon-reload

Em seguida, verifique novamente:

$ systemd-analyze verify \
  /etc/systemd/system/meu-servico.service

A ausência de mensagens normalmente indica que nenhum problema detectável foi encontrado.

13. Examinando o calendário de um timer

A ferramenta também pode interpretar expressões usadas em OnCalendar=:

$ systemd-analyze calendar daily

A saída mostrará a expressão normalizada e a próxima execução:

Original form: daily
Normalized form: *-*-* 00:00:00
Next elapse: Wed 2026-08-26 00:00:00 -03

Teste uma expressão mais específica:

$ systemd-analyze calendar \
  'Mon..Fri *-*-* 08:00:00'

Para mostrar as próximas cinco ocorrências:

$ systemd-analyze calendar \
  --iterations=5 \
  'Mon..Fri *-*-* 08:00:00'

Isso é útil antes de instalar ou modificar um timer, pois permite confirmar se a expressão será interpretada como imaginamos.

14. Avaliando a segurança de um serviço

O comando:

$ systemd-analyze security

avalia os mecanismos de isolamento usados pelos serviços carregados. A saída atribui uma exposição estimada a cada unidade.

Para examinar somente um serviço:

$ systemd-analyze security sshd.service

O relatório considera diretivas como:

• NoNewPrivileges=;
• PrivateTmp=;
• ProtectSystem=;
• ProtectHome=;
• PrivateDevices=;
• RestrictAddressFamilies=;
• CapabilityBoundingSet=;
• SystemCallFilter=;
• RestrictNamespaces=.

A avaliação não procura vulnerabilidades no programa. Ela verifica quanto o arquivo de unidade utiliza os recursos de confinamento oferecidos pelo systemd.

Uma nota ruim não significa necessariamente que o serviço foi comprometido. Da mesma forma, uma nota boa não garante que o programa seja seguro. O resultado serve para orientar o endurecimento da unidade.

15. Analisando os serviços do usuário

O systemd também pode executar uma instância associada ao usuário conectado.

Para medir sua inicialização:

$ systemd-analyze --user time

Liste as unidades de usuário mais demoradas:

$ systemd-analyze --user blame

Examine a cadeia crítica:

$ systemd-analyze --user critical-chain

Gere um gráfico:

$ systemd-analyze --user plot \
  > inicializacao-usuario.svg

Essa análise pode revelar atrasos provocados por:

• serviços gráficos da sessão;
• agentes de autenticação;
• sincronizadores de arquivos;
• programas executados automaticamente;
• serviços definidos em ~/.config/systemd/user;
• aplicativos ativados por D-Bus ou sockets.

Nem todo aplicativo iniciado automaticamente pelo ambiente gráfico é necessariamente gerenciado pelo systemd --user, portanto a análise pode não mostrar tudo o que acontece depois do login.

16. Investigando uma unidade lenta

Suponha que o comando:

$ systemd-analyze blame

mostre:

 15.243s NetworkManager-wait-online.service 

O primeiro passo é verificar se a unidade faz parte da cadeia crítica:

$ systemd-analyze critical-chain \
  NetworkManager-wait-online.service

Depois, examine seu estado:

$ systemctl status \
  NetworkManager-wait-online.service

Consulte os logs:

$ journalctl -b \
  -u NetworkManager-wait-online.service

Verifique quem depende dela:

$ systemctl list-dependencies \
  --reverse \
  NetworkManager-wait-online.service

Examine seu arquivo e eventuais sobrescritas:

$ systemctl cat \
  NetworkManager-wait-online.service

Consulte suas dependências:

$ systemctl list-dependencies \
  NetworkManager-wait-online.service

Somente depois dessa investigação será possível decidir se a espera é:

• necessária;
• consequência de uma configuração incorreta;
• causada por uma interface inexistente;
• exigida por uma montagem remota;
• utilizada por algum serviço;
• dispensável naquele computador.

17. Desativando serviços com segurança

Encontrar um serviço lento não significa que ele deva ser desativado imediatamente.

Antes de alterar qualquer coisa, descubra sua finalidade:

$ systemctl status nome.service

Examine o arquivo:

$ systemctl cat nome.service

Veja quem depende dele:

$ systemctl list-dependencies \
  --reverse \
  nome.service

Confira se está habilitado:

$ systemctl is-enabled nome.service

Se tiver certeza de que o serviço é desnecessário, desative-o:

$ sudo systemctl disable nome.service

Para impedir que seja iniciado imediatamente e nas próximas inicializações:

$ sudo systemctl disable --now nome.service

Após reiniciar o computador, compare novamente:

$ systemd-analyze time

Evite desativar unidades desconhecidas apenas porque aparecem no início de blame. Serviços relacionados a armazenamento, rede, criptografia, login, dispositivos, montagem de sistemas de arquivos e segurança podem ser essenciais.

18. Unidades estáticas e ativação sob demanda

Nem toda unidade precisa estar habilitada diretamente.

Verifique o estado:

$ systemctl is-enabled nome.service

Uma possível resposta é:

 static

Uma unidade estática não possui uma seção de instalação que permita habilitá-la normalmente. Ela pode ser iniciada como dependência de outra unidade ou ativada por:

• socket;
• timer;
• caminho;
• dispositivo;
• barramento D-Bus;
• outra dependência.

Por isso, receber static não indica um erro.

Também é possível que um serviço aparentemente desativado seja iniciado sob demanda. Antes de concluir que uma configuração foi ignorada, examine sockets e timers relacionados:

$ systemctl list-sockets
$ systemctl list-timers

19. Quando o problema está fora do systemd

Nem toda demora pode ser resolvida alterando serviços.

Se o resultado mostrar muito tempo em:

 firmware

investigue:

• ordem de boot;
• detecção de dispositivos;
• inicialização pela rede;
• controladoras;
• firmware desatualizado;
• testes de memória;
• periféricos problemáticos.

Se a demora estiver em:

 loader

verifique:

• tempo de espera do menu;
• configuração do GRUB ou systemd-boot;
• entradas inválidas;
• procura por outros sistemas operacionais;
• discos lentos ou indisponíveis.

Se o maior tempo estiver em:

 kernel

consulte:

$ dmesg -T

Ou use o diário do kernel:

$ journalctl -b -k

Procure por:

• timeouts;
• erros de dispositivos;
• falhas de firmware;
• problemas com controladores;
• discos demorando para responder;
• módulos que falham repetidamente.

Para destacar mensagens de erro do kernel:

$ journalctl -b -k -p warning

O systemd-analyze mostra a distribuição do tempo. A causa pode estar no firmware, no carregador, no kernel, no hardware ou no espaço de usuário.

20. Um roteiro prático de diagnóstico

Uma análise organizada pode seguir esta sequência.

Primeiro, registre o tempo geral:

$ systemd-analyze time

Depois, encontre as unidades demoradas:

$ systemd-analyze blame | head -20

Examine a cadeia que determina o tempo de inicialização:

$ systemd-analyze critical-chain

Gere uma linha do tempo:

$ systemd-analyze plot > inicializacao.svg

Procure serviços com falha:

$ systemctl --failed

Consulte os erros do boot:

$ journalctl -b -p err

Investigue individualmente as unidades suspeitas:

$ systemctl status nome.service

Faça apenas uma alteração por vez, reinicie e repita as medições. Esse cuidado permite saber qual modificação realmente produziu resultado.

## 21. Salvando um relatório da inicialização

Para guardar os resultados antes de fazer alterações:

$ systemd-analyze time  \
  > tempo-inicializacao.txt
$ systemd-analyze blame  \
  > unidades-por-tempo.txt
$ systemd-analyze critical-chain  \
  > cadeia-critica.txt
$ systemd-analyze plot  \
  > inicializacao.svg
$ systemctl --failed  \
  > unidades-com-falha.txt
$ journalctl -b -p warning  \
  > avisos-inicializacao.txt

Depois de alterar a configuração e reiniciar, gere uma segunda série de arquivos para comparar os resultados.

É importante realizar mais de uma medição. Atualizações, verificações de discos, conexões de rede e tarefas ocasionais podem fazer um boot isolado parecer mais lento ou mais rápido do que o normal.

22. Limitações da análise

O systemd-analyze é poderoso, mas seus números precisam de contexto.

Tenha em mente que:

• serviços são iniciados paralelamente;
• blame mostra duração, e não necessariamente impacto;
• um serviço lento pode estar apenas aguardando outro recurso;
• alguns programas continuam inicializando depois de a unidade ser considerada ativa;
• o alvo gráfico pode ser alcançado antes de a área de trabalho estar plenamente utilizável;
• aplicativos iniciados pelo ambiente gráfico podem não aparecer na análise do sistema;
• o cache do sistema de arquivos pode influenciar medições;
• hardware e conectividade podem variar entre inicializações;
• firmware e carregador estão fora da administração direta do systemd;
• desativar uma unidade pode prejudicar recursos que somente são usados ocasionalmente.

A unidade que aparece no topo de blame nem sempre é a que deve ser corrigida. A melhor evidência costuma vir da combinação entre time, blame, critical-chain, plot, systemctl e journalctl.

Resumo dos principais comandos

Conclusão

O systemd-analyze permite transformar a percepção de que “o computador está demorando para iniciar” em informações concretas. Ele mostra quanto tempo foi consumido pelo firmware, carregador, kernel e espaço de usuário, identifica unidades demoradas e revela quais dependências estão no caminho crítico.

O diagnóstico começa com três comandos:

$ systemd-analyze time

O primeiro fornece uma visão geral. O segundo indica quais unidades merecem investigação. O terceiro ajuda a identificar quais delas realmente influenciam o momento em que o sistema alcança seu alvo principal.

Quando esses dados são combinados com o gráfico produzido por systemd-analyze plot, o estado exibido por systemctl e os registros consultados com journalctl, torna-se possível localizar atrasos com muito mais precisão. A partir daí, qualquer otimização deve ser feita com cautela, uma alteração por vez e sempre acompanhada por novas medições.

A descrição completa dos comandos e das limitações da ferramenta está disponível na documentação oficial do systemd-analyze.