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.

Um pouco de consideração antes de iniciar o $EDITOR não irá prejudicar. Para escrever um script rc.d corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro:

A partir dos exemplos que se seguem, veremos o porque é importante conhecer as respostas a essas perguntas.

O script a seguir apenas emite uma mensagem toda vez que o sistema é inicializado:

#!/bin/sh

. /etc/rc.subr

name="dummy"
start_cmd="${name}_start"
stop_cmd=":"

dummy_start()
{
	echo "Nothing started."
}

load_rc_config $name
run_rc_command "$1"

Os pontos a serem observadas são:

# /etc/rc.d/dummy start

Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, os scripts rc.d são controlados pelo rc.conf(5). Felizmente, o rc.subr(8) esconde todas as complicações de nós. O script a seguir usa o rc.conf(5) via rc.subr(8) para ver se ele está habilitado em primeiro lugar, e buscar uma mensagem para mostrar no momento da inicialização. Estas duas tarefas são de fato independentes. Por um lado, um script rc.d pode apenas suportar a ativação e desativação de seu serviço. Por outro lado, um script rc.d obrigatório pode ter variáveis de configuração. Nós vamos fazer as duas coisas no mesmo script:

#!/bin/sh

. /etc/rc.subr

name=dummy
rcvar=dummy_enable

start_cmd="${name}_start"
stop_cmd=":"

load_rc_config $name
: ${dummy_enable:=no} 
: ${dummy_msg="Nothing started."}

dummy_start()
{
	echo "$dummy_msg"
}

run_rc_command "$1"

O que mudou neste exemplo?

# /etc/rc.d/dummy onestart

start_cmd="echo \"$dummy_msg\""

Dissemos anteriormente que o rc.subr(8) poderia fornecer métodos padrão. Obviamente, estes padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e encerrar um programa daemon simples. Vamos supor agora que precisamos escrever um script rc.d para um daemon chamado mumbled. Aqui está:

#!/bin/sh

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

command="/usr/sbin/${name}"

load_rc_config $name
run_rc_command "$1"

Agradavelmente simples, não é? Vamos examinar nosso pequeno script. A única coisa nova a observar é o seguinte:

Vamos adicionar um pouco de carne aos ossos do script anterior e torná-lo mais complexo e cheio de funcionalidades. Os métodos padrões podem fazer um bom trabalho para nós, mas podemos precisar ajustar alguns dos seus aspectos. Agora vamos aprender como ajustar os métodos padrões para as nossas necessidades.

#!/bin/sh

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

command="/usr/sbin/${name}"
command_args="mock arguments > /dev/null 2>&1"

pidfile="/var/run/${name}.pid"

required_files="/etc/${name}.conf /usr/share/misc/${name}.rules"

sig_reload="USR1"

start_precmd="${name}_prestart"
stop_postcmd="echo Bye-bye"

extra_commands="reload plugh xyzzy"

plugh_cmd="mumbled_plugh"
xyzzy_cmd="echo 'Nothing happens.'"

mumbled_prestart()
{
	if checkyesno mumbled_smart; then
		rc_flags="-o smart ${rc_flags}"
	fi
	case "$mumbled_mode" in
	foo)
		rc_flags="-frotz ${rc_flags}"
		;;
	bar)
		rc_flags="-baz ${rc_flags}"
		;;
	*)
		warn "Invalid value for mumbled_mode"
		return 1
		;;
	esac
	run_rc_command xyzzy
	return 0
}

mumbled_plugh()
{
	echo 'A hollow voice says "plugh".'
}

load_rc_config $name
run_rc_command "$1"

# /etc/rc.d/mumbled
Uso: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll)

if checkyesno mumbled_enable; then
        foo
fi

if checkyesno "${mumbled_enable}"; then
        foo
fi

Depois que um script foi escrito, ele precisa ser integrado em rc.d>. O passo crucial é instalar o script em /etc/rc.d (para o sistema base) ou /usr/local/etc/rc.d (para ports). Ambos <bsd.prog.mk > e < bsd.port.mk > fornecer ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequado. Os scripts do sistema devem ser instalados a partir do src /etc/rc.d através do Makefile encontrado lá. Os scripts de porta podem ser instalados usando USE_RC_SUBR conforme descrito em no Manual do Porter.

No entanto, devemos considerar antecipadamente o local do nosso script na sequência de inicialização do sistema. O serviço manipulado pelo nosso script provavelmente depende de outros serviços. Por exemplo, um daemon de rede não pode funcionar sem as interfaces de rede e o roteamento em funcionamento. Mesmo que um serviço pareça não exigir nada, dificilmente pode ser iniciado antes que os sistemas de arquivos básicos tenham sido verificados e montados.

Nós já mencionamos o rcorder(8). Agora é hora de dar uma olhada de perto. Em poucas palavras, o rcorder(8) pega um conjunto de arquivos, examina seu conteúdo e imprime uma lista ordenada por dependência de arquivos do conjunto para stdout. O objetivo é manter as informações de dependência dentro dos arquivos para que cada arquivo possa falar por si só. Um arquivo pode especificar as seguintes informações:

Não é surpresa que rcorder(8) possa manipular apenas arquivos de texto com uma sintaxe próxima a de sh(1). Ou seja, linhas especiais compreendidas por rcorder(8) se parecem com comentários sh(1). A sintaxe de tais linhas especiais é bastante rígida para simplificar seu processamento. Veja rcorder(8) para detalhes.

Além de usar linhas especiais do rcorder(8), um script pode insistir em sua dependência de outro serviço apenas iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não será iniciado automaticamente porque o administrador do sistema o desativou por engano no rc.conf(5).

Com este conhecimento geral em mente, vamos considerar o simples script daemon aprimorado com coisas de dependência:

#!/bin/sh

# PROVIDE: mumbled oldmumble 
# REQUIRE: DAEMON cleanvar frotz
# BEFORE:  LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

command="/usr/sbin/${name}"
start_precmd="${name}_prestart"

mumbled_prestart()
{
	if ! checkyesno frotz_enable && \
	    ! /etc/rc.d/frotz forcestatus 1>/dev/null 2>&1; then
		force_depend frotz || return 1
	fi
	return 0
}

load_rc_config $name
run_rc_command "$1"

Como antes, a análise detalhada segue:

Quando chamado durante a inicialização ou desligamento, um script rc.d deve agir em todo o subsistema pelo qual é responsável. Por exemplo, /etc/rc.d/netif deve iniciar ou parar todas as interfaces de rede descritas por rc.conf(5). Qualquer tarefa pode ser indicada exclusivamente por um único argumento de comando, como start ou stop. Entre a inicialização e o desligamento, os scripts rc.d ajudam o administrador a controlar o sistema em execução, e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede ao rc.conf(5) e então iniciá-lo sem interferir o funcionamento das interfaces existentes. Da próxima vez, o administrador pode precisar desligar uma única interface de rede. No espírito da linha de comando, o respectivo script rc.d solicita um argumento extra, o nome da interface.

Felizmente, rc.subr(8) permite passar qualquer número de argumentos para os métodos do script (dentro dos limites do sistema). Devido a isso, as alterações no próprio script podem ser mínimas.

Como o rc.subr(8) pode obter acesso aos argumentos de linha de comando extra. Deveria pegá-los diretamente? Não por qualquer meio. Primeiro, uma função sh(1) não tem acesso aos parâmetros posicionais de seu chamador, mas o rc.subr(8) é apenas uma despedida de tais funções. Em segundo lugar, a boa maneira de rc.d determina que é para o script principal decidir quais argumentos devem ser passados para seus métodos.

Portanto, a abordagem adotada por rc.subr(8) é a seguinte: run_rc_command transmite todos os seus argumentos, mas o primeiro um para o respectivo método na íntegra. O primeiro, omitido, argumento é o nome do próprio método: start,stop, etc. Ele será deslocado por run_rc_command, então o que é $2 na linha de comando original será apresentado como $1 ao método, e assim por diante.

Para ilustrar essa oportunidade, vamos modificar o script fictício primitivo para que suas mensagens dependam dos argumentos adicionais fornecidos. Aqui vamos nós:

#!/bin/sh

. /etc/rc.subr

name="dummy"
start_cmd="${name}_start"
stop_cmd=":"
kiss_cmd="${name}_kiss"
extra_commands="kiss"

dummy_start()
{
        if [ $# -gt 0 ]; then
                echo "Greeting message: $*"
        else
                echo "Nothing started."
        fi
}

dummy_kiss()
{
        echo -n "A ghost gives you a kiss"
        if [ $# -gt 0 ]; then
                echo -n " and whispers: $*"
        fi
        case "$*" in
        *[.!?])
                echo
                ;;
        *)
                echo .
                ;;
        esac
}

load_rc_config $name
run_rc_command "$@"

Quais mudanças essenciais podemos notar no script?

# /etc/rc.d/dummy start
Nothing started.
# /etc/rc.d/dummy start Hello world!
Greeting message: Hello world!

# /etc/rc.d/dummy kiss
A ghost gives you a kiss.
# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu...
A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu...

O artigo original de Luke Mewburn oferece uma visão geral do rc.d e o raciocínio detalhado que o levou a suas decisões de design. Ele fornece informações sobre toda o framework do rc.d e o seu lugar em um moderno sistema operacional BSD.

As páginas de manual rc (8), rc.subr(8) e rcorder(8) documentam os componentes do rc.d com grande detalhe. Você não pode usar totalmente o poder do rc.d sem estudar as páginas de manual e se referir a elas enquanto escreve seus próprios scripts.

A sua principal fonte de inspiração são os exemplos da vida real, existentes em no /etc/rc.d de um sistema vivo. Seu conteúdo é fácil e agradável de ler, porque a maioria dos cantos ásperos estão escondidos fundo no rc.subr(8). Tenha em mente que os scripts /etc/rc.d não foram escritos por anjos, então eles podem sofrer de bugs e decisões sub-ótimas de design. Agora você pode melhorá-los!