01 - Runlevels (0 a 6)

A arquitetura do SysVinit gerencia o ciclo de vida do sistema operacional fundamentada no conceito de uma Máquina de Estados Finitos (Finite State Machine - FSM). Neste paradigma, o sistema só pode existir em um único estado mutuamente exclusivo em qualquer dado instante. Esses estados arquiteturais são denominados Runlevels (Níveis de Execução). Cada runlevel define um perfil operacional rígido, determinando quais subsistemas, daemons e abstrações de hardware devem estar ativos ou inativos.

A transição entre esses estados não é orgânica ou baseada em dependências resolvidas dinamicamente, mas sim uma orquestração determinística de desligamento e inicialização de processos governada pelo PID 1 (init) e executada por um script despachante central (geralmente /etc/rc.d/rc ou /etc/init.d/rc).

1. A Taxonomia Canônica dos Runlevels (0 a 6)

Embora o UNIX System V original permitisse uma miríade de definições, o ecossistema Linux padronizou o uso de sete runlevels numéricos primários (0 a 6) e alguns runlevels alfabéticos para manutenção de estado interno. Cada nível foi projetado com uma semântica específica, herdando restrições de redes e abstrações de vídeo da era dos mainframes e terminais burros.

Runlevel 0: Halt (Paralisação do Sistema)

O estado de desligamento absoluto. A transição para este runlevel instrui o sistema a iniciar a rotina terminal.

• Mecânica: O despachante executa estritamente scripts de terminação (K - Kill). Ele envia sinais SIGTERM e posteriormente SIGKILL para todos os daemons, desmonta os sistemas de arquivos (ou os remonta como leitura-apenas, se a desmontagem falhar) e desativa a paginação de memória (swapoff).
• Desfecho: A última instrução deste runlevel é a invocação do binário /sbin/halt, que por sua vez executa a syscall de reinicialização com a flag LINUX_REBOOT_CMD_POWER_OFF, engatilhando a interface ACPI para cortar a energia física do hardware.

Runlevel 1 (ou 'S', 's'): Single-User Mode (Modo de Manutenção)

Um estado de emergência e diagnóstico profundo, projetado para reparar danos catastróficos que impedem o boot normal, como corrupção do /etc/fstab ou falhas na estrutura do sistema de arquivos raiz (/).

• Semântica: O sistema de arquivos raiz é frequentemente montado sem suporte a gravação num primeiro momento. A pilha de rede (TCP/IP) é completamente ignorada e nenhum daemon não-essencial é iniciado.
• Autenticação: Historicamente, este runlevel burla o /bin/login e o PAM. Ele invoca diretamente o binário /sbin/sulogin no /dev/console (ou tty1). O sulogin exige a senha do superusuário (root); se fornecida, ele injeta um shell de privilégio máximo com acesso irrestrito ao hardware, isolado de acessos remotos.

Runlevel 2: Multi-User Mode sem NFS (Historicamente)

A semântica deste estado é a que mais sofreu mutações entre diferentes vertentes do Linux. No UNIX SVR4 clássico, o Runlevel 2 representava um estado onde o sistema operava com múltiplos usuários locais, mas sem exportar ou montar volumes via rede (NFS - Network File System).

• Uso Moderno: Em distribuições derivadas do Red Hat, ele mantinha a semântica sem NFS. Contudo, em sistemas da família Debian/Ubuntu, o Runlevel 2 foi redefinido como o estado padrão de operação total (incluindo rede e interface gráfica, dependendo da instalação). Esta divergência filosófica significa que, no Debian, os níveis 2, 3, 4 e 5 são funcionalmente idênticos logo após a instalação, a menos que o administrador os modifique manualmente.

Runlevel 3: Full Multi-User Mode (Console de Texto)

O estado de produção primário para infraestruturas de servidores (headless).

• Mecânica: A pilha de rede é totalmente inicializada, os daemons de roteamento, servidores web, bancos de dados e serviços de monitoramento são acionados. Os sistemas de arquivos remotos (NFS, iSCSI, CIFS) são montados.
• Interface: Nenhuma abstração do servidor X11 ou Wayland é carregada. A interação humana ocorre puramente através de portas TTY locais acionadas pelo binário getty ou via emuladores de terminal remotos através do protocolo SSH (porta 22).

Runlevel 4: Undefined (Definido pelo Usuário)

A arquitetura SysVinit reservou o estado 4 propositalmente para o administrador do sistema. Ele é distribuído em branco pela maioria das distribuições (comporta-se como um espelho do Runlevel 3 até ser configurado).

• Casos de Uso: Comumente empregado em engenharia de sistemas customizados, como ambientes de quiosque (kiosk mode), rotinas de backup restritas, ou estados de alta segurança onde apenas um subconjunto de daemons vitais está ativo, criando um perfil alternativo de inicialização sem alterar a configuração do servidor de produção (Runlevel 3).

Runlevel 5: X11 / Graphical Mode

A arquitetura de desktop ou de estações de trabalho interativas. É estruturalmente o Runlevel 3 acompanhado do subsistema de interface gráfica de usuário (GUI).

• Mecânica: Além de subir a rede e os daemons, o último script iniciado neste nível costuma ser o Display Manager (como GDM, LightDM, XDM ou SDDM).
• Orquestração: O Display Manager se apropria do /dev/tty7 (historicamente) ou /dev/tty1 (modernamente), inicializa o servidor gráfico, desenha o framebuffer e gerencia o loop de autenticação visual via módulos PAM antes de entregar a sessão para um gerenciador de janelas.

Runlevel 6: Reboot (Reinicialização)

Semelhante ao Runlevel 0 na sua mecânica de desmontagem, mas com um desfecho direcionado a ciclo de energia.

• Mecânica: O sistema mata agressivamente todos os daemons, força a gravação (sync) dos buffers de disco sujos do VFS para a mídia física, e desmonta o armazenamento.
• Desfecho: O binário /sbin/reboot é invocado, chamando a syscall de reboot com a flag LINUX_REBOOT_CMD_RESTART, instruindo o processador a reinicializar seus registradores e devolver o controle ao firmware da placa-mãe (BIOS/UEFI), reiniciando todo o ciclo POST.

2. A Mecânica de Transição de Estado (telinit)

O PID 1 (init) não muda de estado por vontade própria. Ele atua como um ouvinte passivo após a inicialização, aguardando instruções do administrador através do utilitário telinit (Tell Init).

O telinit é um binário em espaço de usuário (frequentemente um symlink apontando para o próprio binário do init) que não executa o desligamento de serviços por si só. Quando um administrador digita telinit 3, a seguinte cascata arquitetural ocorre:

1. Comunicação Interprocessos (IPC): O telinit abre um FIFO (First-In, First-Out) ou named pipe localizado em /dev/initctl.
2. Injeção de Comando: Ele escreve uma estrutura C magicamente formatada neste pipe solicitando a transição para o nível '3'.
3. Despertar do PID 1: O processo init, que dormia em um loop select(), detecta I/O no /dev/initctl. Ele lê a solicitação, valida os privilégios do chamador e atualiza sua variável de estado interna.
4. Auditoria: O init registra a mudança de estado nos bancos de dados de contabilidade do sistema (/var/run/utmp para o estado atual e /var/log/wtmp para histórico de conexões/boots), permitindo que comandos como who -r mostrem o estado anterior e o atual.
5. Ação: O init invoca a linha configurada em /etc/inittab correspondente ao estado alvo, delegando o trabalho sujo ao script /etc/rc.d/rc 3.

3. Estados Especiais e Gestão do inittab

A arquitetura também definiu pseudo-runlevels que não alteram a execução do sistema, mas alteram o comportamento do orquestrador.

Runlevels a, b, c (Modo On-Demand)

Embora muito raros em implementações modernas do SysVinit, os níveis a, b e c processam exclusivamente diretivas marcadas com a ação ondemand no /etc/inittab. Se o telinit a for acionado, o init executará os daemons atrelados àquele runlevel específico sem alterar o nível de execução global da máquina, funcionando como um mecanismo primitivo de "serviço sob demanda".

O Sinal de Recarregamento (telinit q ou Q)

Se o administrador alterar o arquivo de controle central /etc/inittab (por exemplo, alterando o estado padrão em id:3:initdefault:), essa alteração não é processada automaticamente, já que o PID 1 lê esse arquivo apenas durante o boot ou após uma instrução explícita.
Ao invocar telinit q (Query/Quiet), o init relê e recompila a matriz do inittab na RAM. Ele avaliará se algum processo com a diretiva respawn foi removido (caso em que ele enviará um SIGKILL para o PID associado) ou se novos processos foram adicionados, instanciando-os sem perturbar o runlevel vigente do sistema operante.

4. O Paradigma de Idempotência e a Responsabilidade dos Scripts

Durante a transição entre runlevels (por exemplo, do 3 para o 5), o despachante /etc/rc.d/rc executará todos os scripts com o prefixo S (Start) dentro do diretório /etc/rc5.d/. Como muitos serviços do nível 3 também existem no nível 5 (como a rede ou o SSH), o SysVinit exige que a engenharia de cada script de daemon seja idempotente.

O rc não verifica confiavelmente se o daemon já está rodando antes de emitir a instrução start. A responsabilidade de evitar conflitos estruturais é delegada ao próprio script bash do serviço. Um script SysV bem desenhado realiza verificações rígidas através do diretório /var/lock/subsys/ (comum no ecossistema RHEL) ou da existência e vivacidade de PIDs armazenados em /var/run/. Se o script for chamado para iniciar um processo que já está vivo sob o comando do runlevel anterior, ele deve detectar o estado graciosamente e terminar com código de saída de sucesso (0), impedindo o corrompimento de sockets ou o disparo de processos zumbis na transição da FSM.