A utilidade systemd-analyze, integrada nas distribuições Linux que utilizam o sistema init systemd, permite aos utilizadores identificar rapidamente as causas de processos de arranque lentos. Ao executar comandos simples, decompõe os tempos de inicialização em componentes kernel e userspace e destaca os serviços que causam atrasos. Esta ferramenta ajuda os administradores a fazer ajustes direcionados para melhorar as velocidades de arranque sem adivinhação.
Os utilizadores de Linux que experienciam tempos de arranque lentos em distribuições baseadas em systemd, como Ubuntu ou Fedora, podem recorrer à ferramenta integrada systemd-analyze para um diagnóstico rápido. Como descrito em guias técnicos, a ferramenta analisa a sequência de inicialização gerida pelo systemd, reportando durações para etapas como firmware, bootloader, kernel e userspace. Executar o comando básico systemd-analyze fornece um resumo do tempo total de arranque. Por exemplo, um caso mostra o arranque concluído em 6,669 segundos para o kernel mais 30,368 segundos para userspace, totalizando 37,037 segundos, com o alvo gráfico alcançado após 27,479 segundos em userspace. Uma versão compacta, systemd-analyze time, oferece decomposições semelhantes, revelando frequentemente o userspace como o principal gargalo em sistemas SSD. A opção blame lista as unidades systemd por tempo de inicialização, da mais longa para a mais curta. Atrasos comuns provêm de serviços como apt-daily.service (57,158 segundos num caso), que gere verificações diárias de atualizações em sistemas baseados em Debian; snapd.service (17,609 segundos); e docker.service (10,647 segundos). Os guias aconselham rever esta lista para identificar serviços desativáveis, como adiar runtimes de contentores como o Docker se não forem necessários imediatamente, advertindo contra a desativação de tarefas essenciais como atualizações automáticas. Para uma visão mais profunda, systemd-analyze critical-chain rastreia o caminho de dependências que atrasa o alvo predefinido. Uma saída pode mostrar graphical.target à espera de multi-user.target, que por sua vez depende de docker.service (iniciando aos 16,830 segundos e demorando 10,647 segundos). Isto revela gargalos, como serviços de espera de rede ou montagens mal configuradas que causam timeouts de 30-90 segundos. Finalmente, systemd-analyze plot > boot.svg gera uma linha de tempo visual SVG do processo de arranque, ilustrando dependências paralelas e em série. Abrir o ficheiro num browser destaca unidades de arranque tardio, como aquelas à volta dos 18 segundos em visuais de exemplo. Os administradores reportam ganhos significativos, incluindo reduções de 20-40% no tempo de userspace em sistemas SSD, aplicando mudanças como reagendar temporizadores ou remover pacotes desnecessários como cloud-init em configurações não-cloud. Estas modificações devem ser documentadas para reversibilidade, garantindo a fiabilidade do sistema. 0.0 0.0 null
