Scripts rc.d práticos no BSD

Historicamente o BSD tinha um script de inicialização monolítico, o /etc/rc. Ele era chamado pelo init( 8) no momento da inicialização do sistema e executava todas as tarefas necessárias para a operação multi-usuário: verificação e montagem do sistemas de arquivos, configuração de rede, iniciava daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-lo. Com poucas exceções, o /etc/rc teve que ser modificado, e os verdadeiros hackers gostaram disso.

O problema real com a abordagem monolítica era que ela não fornecia nenhum controle sobre os componentes individuais iniciados a partir do /etc/rc. Por exemplo, o /etc/rc não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo daemon manualmente, matá-lo, esperar até que ele realmente finalizasse, então procurar pelas flags no /etc/rc, e finalmente digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço de reinicialização consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o único script não cumpriu o objetivo dos scripts: tornar a vida do administrador do sistema mais fácil.

Mais tarde, houve uma tentativa de dividir algumas partes do /etc/rc para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o /etc/netstart para configurar a rede. Ele permitia acessar a rede a partir do modo single-user, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o /etc/netstart mudou para /etc/rc.network. Este último não era mais um script comum; ele era composto por um emaranhado de funções sh(1) chamadas pelo /etc/rc em diferentes estágios da inicialização do sistema. No entanto, a medida que as tarefas de inicialização cresciam variadas e sofisticadas, a abordagem “quase modular” tornou-se ainda mais engessada do que o monolítico /etc/rc.

Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se curvar para satisfazer as necessidades de desenvolvimento rápido dos sistemas operacionais baseados no BSD. Tornou-se óbvio, finalmente, que mais passos eram necessários no caminho para construção de um sistema rc extensível e customizável. Assim nasceu o BSD rc.d. Seus pais reconhecidos foram o Luke Mewburn e a comunidade do NetBSD. Mais tarde ele foi importado para o FreeBSD. Seu nome se refere à localização dos scripts do sistema para serviços individuais, que é o /etc/rc.d. Em breve, vamos aprender sobre mais componentes do sistema rc.d e vamos ver como os scripts individuais são invocados.

As idéias básicas por trás do BSD rc.d são modularidade fina e reutilização de código. Modularidade fina significa que cada “serviço básico”, como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script sh() capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando para o script. O script /etc/rc ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento start. É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento stop, o que é feito pelo /etc/rc.shutdown. Observe como isso segue de perto o modo Unix de ter um conjunto de pequenas ferramentas especializadas, cada uma cumprindo sua tarefa da melhor forma possível. Reutilização de código significa que operações comuns são implementadas como funções sh(1) e coletadas em /etc/rc.subr . Agora, um script típico pode conter apenas algumas linhas de código sh(1). Finalmente, uma parte importante do framework do rc.d é rcorder(8), o qual ajuda o /etc/rc a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o /etc/rc.shutdown, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização.

O design do BSD rc.d é descrito no artigo original de Luke Mewburn, e os componentes do rc.d são documentados em grande detalhe nas respectivas páginas de manual. No entanto, pode não parecer óbvio para um novato em rc.d como amarrar os inúmeros pedaços juntos para criar um script bem estilizado para uma tarefa específica. Portanto, este artigo tentará uma abordagem diferente para descrever o rc.d. Ele mostrará quais recursos devem ser usados em vários casos típicos e por quê. Note que este não é um documento explicativo porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no domínio do rc.d. Nem este artigo é um substituto para as páginas de manual relevantes. Não hesite em consultá-los para obter uma documentação mais formal e completa ao ler este artigo.

Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script sh(1) para poder dominar o rc.d. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em rc(8).

Este artigo foca no branch rc.d do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs rc.d do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script.