Seu smartphone, no primeiro uso inicia normalmente, sem retardos. Com o tempo, a medida que vai instalando seus aplicativos, tende a ficar mais lento. Analogamente, seu sistema Linux pode sofrer retardos na inicialização do sistema, oriundos de diversos processos iniciados em tempo de boot.
Dependendo de quais serviços tenha configurado, esses processos causam pequenos atrasos no tempo de inicialização no Linux. Sendo assim, entenda como isso acontece e descubra quais processos podem estar causando esse “probleminha” imperceptível para maioria dos usuários; principalmente para os iniciantes.
Contextualizando
Antes de começarmos, entenda que um processo é a forma que o sistema operacional tem para representar um programa em execução. É o processo que utiliza os recursos do computador – processador, memória, etc – para a realização das tarefas para as quais a máquina é destinada. Inclusive, todo sistema possui um processo inicializador, no caso do Linux o processo init; o primeiro processo do Linux depois que o Kernel é iniciado.
Muito além do kernel – conheça todos os elementos que formam a estrutura do sistema Linux
Saber lidar com processos pode ser crucial para manter um computador funcionando e executando suas tarefas normalmente. Isso se torna essencial a administradores de sistemas, mas é importante, até mesmo, ao usuário do cotidiano.
Tendo isso em vista, as distribuições Linux usam um sistema de inicialização carregado, através do processo init, pelo bootloader do sistema. Atualmente, existem alguns, entre eles Systemd, SysVinit ou SysV e o upstart. O Systemd se tornou, há alguns anos, o novo padrão de inicialização no principais sistemas Linux. O Systemd veio em detrimento do uso do SysVinit ou SysV, presente ainda em algumas distribuições Linux. E o upstart foi criado pela Canonical, mantenedora do Ubuntu, e também migrado para o Systemd, na maioria das suas versões.
Sendo assim, vou mostrar na prática como descobrir quais processos podem estar retardando o tempo de inicialização no Linux e como atenuar esse problema.
Tempo de inicialização no Linux
Primeiramente, é preciso saber qual sistema de inicialização está carregado no seu sistema Linux. Simplesmente, verifique, executando um comando “ls”, em cada diretório abaixo, para obter essa informação:
$ ls /usr/lib/systemd$ ls /usr/share/upstart$ ls /etc/init.d- 1) /usr/lib/systemd – Systemd presente no sistema
- 2) /usr/share/upstart – Upstart presente no sistema
- 3) /etc/init.d – SysV init presente no sistema
Logo após, é preciso identificar quais processos demandam mais tempo, e se possível, desativá-los. Assim, teremos uma visão de quais recursos são utilizados durante o boot. No caso do Systemd, execute:
$ systemd-analyze
Startup finished in 11.822s (firmware) + 5.590s (loader) + 2.438s (kernel) + 9.614s (userspace) = 29.466s
graphical.target reached after 9.614s in userspaceO comando anterior mostrou um resumo global de tempo de inicialização dos processos no sistema, em torno de 29s. Mas, para obter lista detalhada de quais processos demandam mais tempo, execute:
$ systemd-analyze blame
7.087s NetworkManager-wait-online.service
1.130s docker.service
846ms [email protected]
809ms systemd-logind.service
769ms lvm2-monitor.service
610ms udisks2.service
590ms man-db.service
463ms logrotate.service
409ms dev-sdb6.device
224ms org.cups.cupsd.service
{...}
Encontrar gargalos
Uma longa lista dos processos iniciados durante o boot e o tempo gasto por eles foi apresentado como resposta. O utilitário systemd-analyse também pode mostrar gargalos no desempenho de inicialização. O comando a seguir mostra serviços iniciando com indicadores de quando eles começaram e quanto tempo levaram para iniciar:
$ systemd-analyze critical-chain
└─multi-user.target @9.614s
└─docker.service @8.482s +1.130s
└─network-online.target @8.481s
└─NetworkManager-wait-online.service @1.393s +7.087s
└─NetworkManager.service @1.318s +71ms
└─dbus.service @1.316s
└─basic.target @1.313s
└─sockets.target @1.313s
└─docker.socket @1.312s +764us
└─sysinit.target @1.309s
└─systemd-update-done.service @1.304s +4ms
└─ldconfig.service @1.160s +143ms
└─local-fs.target @1.158s
└─run-user-120.mount @3.295s
{...}
Os números após o símbolo “@” mostram quando o alvo foi atingido e o número após o “+” mostra quanto tempo demorou para iniciar um serviço. No meu caso, podemos ver que o serviço NetworkManager-wait-online está levando um tempo maior (7,087 segundos) para iniciar, o que é mais da metade do tempo total de inicialização. É preciso corrigir sua configuração ou descobrir por que está demorando tanto para concluir suas tarefas.
Diminuir tempo de inicialização
Tenha cuidado a realizar as operações a seguir, pois o risco é alto caso remova algum processo importante para o boot do sistema. Recomendo que antes teste em ambiente não crítico e faça backup antes de ir para ambiente real.
Alternativamente, sabendo da situação, queremos que o serviço NetworkManager-wait-online gaste menos tempo que o atual para iniciar. Em resumo, esse processo é responsável por garantir que a rede fique ativa antes que certas etapas sejam feitas retardando a inicialização do sistema até que uma conexão de rede seja estabelecida.Ele usa um utilitário chamado nm-online (conjunto de ferramentas do NetworkManager) que verifica, no boot, se alguma rede já foi estabelecida (cabo, wireless e outras).
Por ser um processo essencial para o sistema, desativá-lo não é uma ação recomendada. Contudo, como alternativa, podemos identificar quais conexões WiFi, por exemplo, que já tenha sido realizada, podem ser eliminadas diminuindo as tarefas do NetworkManager.
Ou, mais avançado, podemos ajustar alguns parâmetros de configurações do serviço. Nesse caso, você pode alterar o arquivo /lib/systemd/system/NetworkManager-wait-online.service, como root, e mudar de 30 (padrão) para 10 segundos de espera (–timeout).
Execute as mudanças usando o editor nano e tenha consciência que essa mudança pode causar falhas em outros services que dependam do status da rede. Por sua conta e risco:
$ sudo nano /lib/systemd/system/NetworkManager-wait-online.service
[Unit]
Description=Network Manager Wait Online
Documentation=man:nm-online(1)
Requires=NetworkManager.service
After=NetworkManager.service
Before=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=10
RemainAfterExit=yes
[Install]
WantedBy=network-online.target
A seguir, “informar” o systemd das mudanças:
$ sudo systemctl daemon-reload
Reinicie o sistema e após o reinício, execute o comando “systemd-analyze critical-chain” novamente e veja o tempo “ganho”. No meu caso, tive uma perda causando um atraso de 4s por conta do serviço docker que foi sensível ao atraso configurado:
$ systemd-analyze critical-chain
└─multi-user.target @12.326s
└─docker.service @8.482s +2.230s
└─network-online.target @8.481s
└─NetworkManager-wait-online.service @1.393s +7.087s
└─NetworkManager.service @1.318s +71ms
{...}
Mas, provavelmente, ao iniciar o sistema, você não irá precisar acessar a internet imediatamente – desde que nenhum outro processo dependa disso. Se for este o caso, podemos desativar o NetworkManager-wait-online.service do boot. A rede só vai entrar alguns segundos depois do login:
$ sudo systemctl disable NetworkManager-wait-online.service
Novamente, reinicie o sistema e após o reinício, execute o comando “systemd-analyze critical-chain” novamente e veja o tempo “ganho”. No meu caso, foi um ganho de 6s nesse cenário:
$ systemd-analyze critical-chain
graphical.target @3.931s
└─multi-user.target @3.930s
└─docker.service @1.330s +2.600s
└─network-online.target @1.329s
└─network.target @1.327s
└─wpa_supplicant.service @2.214s +26ms
└─basic.target @1.255s
└─sockets.target @1.255s
{...}
Conclusão
É importante salientar que não foram apresentados todas as técnicas que melhoram por completo o tempo de inicialização no Linux. O foco foi a nível de processos do sistema. Dentre outras alternativas para obter ganhos significativos, temos: alterar o tempo do GRUB e/ou trocar seu disco HDD por SSD, já que são melhores para ler arquivos pequenos, colocados aleatoriamente, que tendem a melhorar o tempo de inicialização.
Por fim, nesse cenário de processos, cada usuário terá uma resposta diferente e maneiras para atenuar o problema, tendo em vista que cada sistema possui sua pilha de processos. Mas, de qualquer maneira espero que este artigo tenha ajudado!
