Boot, serviços e arquivos de inicialização

Ao ligar o micro, o primeiro software que é carregado é o BIOS da placa-mãe. Ele faz a contagem da memória RAM e realiza uma checagem rápida dos dispositivos instalados.

Depois de fazer seu trabalho, o BIOS carrega o sistema operacional, que pode ser carregado a partir de diversas fontes, incluindo o HD, um CD-ROM ou DVD, um pendrive, ou até mesmo via rede (como é feito no LTSP e em outros sistemas de terminais leves), respeitando a ordem definida na configuração do Setup.

No caso dos HDs, é lido o primeiro setor do disco rígido, o famoso “Master Boot Record” ou MBR. Nele é gravado o gerenciador de boot, que é o responsável pelo carregamento do sistema. É a presença dele que permite que você instale mais de um sistema operacional no mesmo micro e possa escolher entre eles na hora do boot.

No Linux, o gerenciador mais usado é o grub (com uma pequena participação do lilo), enquanto no Windows, é usado o NTLDR. O MBR tem espaço para apenas um gerenciador de boot, por isso é preciso prestar atenção na configuração ao instalar vários sistemas, já que, por default, cada sistema subscreve o gerenciador de boot do anterior ao ser instalado.

Apesar de sua vital importância, o MBR engloba um único setor do HD, meros 512 bytes. Devido a isso, ele é, na verdade, usado para armazenar apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o executável do gerenciador de boot em um ponto específico do HD.

O bootstrap do gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes são usados para armazenar a tabela de partições, que guarda informações sobre onde cada partição começa e termina. Programas de particionamento, como o cfdisk, nada mais fazem do que alterar as informações na tabela de partições. Quando ela é perdida ou danificada (seja qual for o motivo), todas as partições desaparecem e você precisa ir atrás de um programa de recuperação de dados.

O gerenciador de boot tem a função de carregar o kernel e, a partir dele, todo o restante do sistema. Tanto o grub quando o lilo podem ser configurados para carregar também o Windows ou outros sistemas instalados em dual-boot ou multi-boot. A maioria das distribuições atuais configuram isso automaticamente durante a instalação.

Inicialmente, o kernel é um arquivo compactado e somente-leitura, o “/boot/vmlinuz”. Logo no início do boot, ele é descompactado em uma área reservada da memória RAM e roda a partir daí, aproveitando o fato de que a memória RAM é muito mais rápida que o HD. Este executável principal do kernel nunca é alterado durante o uso normal do sistema, ele muda apenas quando você recompila o kernel manualmente ou instala uma nova versão.

Depois de carregado, a primeira coisa que o kernel faz é montar a partição raiz, onde o sistema está instalado, inicialmente como somente-leitura. Neste estágio ele carrega o init, o software que inicia o boot normal do sistema, lendo os scripts de inicialização e carregando os módulos e softwares especificados neles. O arquivo de configuração do init é o “/etc/inittab“. Ele é geralmente o primeiro arquivo de configuração lido durante o boot.

Todas essas etapas são realizadas por scripts, localizados na pasta “/etc/init.d”, que executam os comandos apropriados para inicializar os serviços e executar as demais operações necessárias. Alguns deles são executados apenas durante o boot (verificando alguma configuração, por exemplo), enquanto outros inicializam serviços que ficam ativos continuamente.

Um bom exemplo é o cups, que é o serviço responsável pelo suporte a impressão. Ele é usado tanto para imprimir em impressoras locais quando em impressoras de rede e é usado também quando você precisa compartilhar a impressora com outras máquinas da rede. Ele vem instalado por padrão em quase todas as distribuições e é controlado através do script “/etc/init.d/cups” (ou “/etc/init.d/cupsys”, dependendo da distribuição).

Se você quisesse desativá-lo temporariamente, por exemplo, usaria:

# /etc/init.d/cups stop

Para ativá-lo novamente depois, usaria:

# /etc/init.d/cups start

O mesmo se aplica a quase todos os outros serviços, como no caso do “samba” (responsável pelo compartilhamento de arquivos), o “bluetooth” (responsável pelo suporte a transmissores Bluetooth) e assim por diante. Eles são também chamados de “daemons”, um termo usado em relação a serviços que ficam ativos continuamente, executando alguma função.

O que determina se cada serviço vai ser ou não ativado durante o boot, não é o fato de estar ou não instalado, mas sim, a presença de um link simbólico criado dentro de uma das pastas de inicialização do sistema. Por padrão, são executados primeiro os links que estão dentro da pasta “/etc/rcS.d/” (que inclui os serviços essenciais, executados logo no início do boot) e, em seguida, os links dentro da pasta “/etc/rc5.d/“, que inclui os demais serviços.

O número (5 no exemplo) indica o runlevel que será usado, que pode ser um valor de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização. Esta foi uma forma encontrada pelas distribuições para ter vários “profiles”, que podem ser usados de acordo com a situação.

A configuração mais comum é usar o runlevel 1 como um modo de recuperação, no qual apenas os serviços essenciais para concluir o boot são carregados, sem ambiente gráfico e sem suporte a rede. Hoje em dia, o runlevel 1 é pouco usado, pois é mais fácil corrigir problemas dando boot com um live-CD e resolvendo os problemas através dele, mas a possibilidade continua disponível.

Em seguida temos o runlevel 3, onde quase todos os serviços são carregados, com exceção do ambiente gráfico (este modo é muito usado em servidores). Finalmente, temos o runlevel 5, que corresponde ao modo “normal”, onde o ambiente gráfico é carregado, junto com todos os outros serviços. Como em outros casos, existem variações; o Slackware, por exemplo, utiliza o runlevel 4 para carregamento do ambiente gráfico, enquanto o Ubuntu usa um sistema completamente diferente.

Usando o runlevel 5, são carregados os scripts colocados dentro da pasta “/etc/rc5.d/”, enquanto que, usando o runlevel 3, são carregados os scripts dentro da pasta “/etc/rc3.d/”. Nada impede que você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e links simbólicos e não uma caixa preta.

É possível executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante o boot mudam de distribuição para distribuição, de acordo com o que os desenvolvedores consideram mais adequado. Uma distribuição que carregue mais serviços, pode oferecer mais recursos e executar mais funções automaticamente, enquanto outra, que inicialize apenas os componentes essenciais, pode consumir menos memória e oferecer um melhor desempenho em micros antigos, por exemplo.

O Ubuntu inaugurou o uso de um novo sistema de inicialização, batizado de Upstart (http://upstart.ubuntu.com/). Nele, o processo de inicialização é simplificado (embora também perca parte da flexibilidade) e deixa de existir diferença entre os runlevels de 2 a 5, que passam a utilizar a mesma configuração, carregando o ambiente gráfico por default, o que essencialmente elimina a diferenciação entre os modos. Se você tiver a curiosidade de rodar o comando “runlevel”, que mostra qual runlevel está sendo usado, ele reportará:

$ runlevel

N 2

Em outras distribuições, o runlevel 2 é configurado como um modo de recuperação, sem suporte a rede nem ambiente gráfico, mas no Ubuntu ele é o nível padrão, onde são carregados todos os serviços. Se você verificar a configuração dos modos 3, 4 e 5, vai perceber que a configuração é a mesma em todos eles.

Outro sintoma do uso do Upstart é que o arquivo “/etc/inittab” deixa de existir, dando lugar ao “/etc/event.d/rc-default“, que passa a ser o novo responsável por disparar o processo de inicialização do sistema.

O utilitário padrão para a configuração dos serviços no Ubuntu é o services-admin, disponível no “Sistema > Administração > Serviços”:

O problema é que ele mostra apenas um conjunto de serviços considerados “opcionais”, escondendo diversos serviços que são considerados componentes essenciais do sistema, como por exemplo o cups.

Se você quiser ver a lista completa, pode dar uma olhada no conteúdo da pasta “/etc/rc2.d“:

Naturalmente, você só deve se meter a desativar os serviços não listados no services-admin se souber o que está fazendo, já que a maior parte deles são mesmo componentes importantes. Desativando o dbus, por exemplo, boa parte das funções de detecção de hardware, juntamente com diversos programas que o utilizam para trocar mensagens, deixam de funcionar.

Para desativar os serviços manualmente, use o comando “update-rc.d -f nome remove”, como em:

# update-rc.d -f cups remove

Ele remove os links que apontarem para o serviço em todas as pastas de inicialização, fazendo com que ele deixe de ser carregado durante o boot. Se você quiser desativar o serviço na hora, pode desativá-lo usando o comando “/etc/init.d/nome stop”, como em “/etc/init.d/cups stop”.

Para reativar a inicialização do serviço posteriormente, use o comando “update-rc.d -f nome defaults”, como em:

# update-rc.d -f cups defaults

Ele recria os links simbólicos, restaurando a configuração original. Estes mesmos comandos podem ser usados em outras distribuições derivadas do Debian. No caso do Mandriva e do Fedora, é usado o comando “chkconfig”, como em “chkconfig nome on” (ativa) e “chkconfig nome off” (desativa).