4. Um script fictício configurável

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_enable1

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

load_rc_config $name2
: ${dummy_enable:=no} 3
: ${dummy_msg="Nothing started."}4

dummy_start()
{
	echo "$dummy_msg"5
}

run_rc_command "$1"

O que mudou neste exemplo?

1

A variável rcvar especifica o nome da variável do botão ON/OFF.

2

Agora o load_rc_config é invocado anteriormente no script, antes que qualquer variável do rc.conf(5) seja acessada.

Nota:

Ao examinar os scripts rc.d, tenha em mente que o sh(1) adia a avaliação de expressões em uma função até que a função seja chamada. Portanto, não é um erro invocar load_rc_config tão tarde quanto antes do run_rc_comman e ainda acessar as variáveis do rc.conf(5) a partir do método das funções exportadas para o run_rc_command. Isto ocorre porque as funções do método devem ser chamadas por run_rc_command, que é chamado após o load_rc_config.

3

Um aviso será emitido pelo run_rc_command se o próprio rcvar estiver definido, mas a variável de knob indicada não estiver definida. Se o seu script rc.d for para o sistema base, você deve adicionar uma configuração padrão para o knob no /etc/defaults/rc.conf e documentá-lo em rc.conf(5). Caso contrário, será o seu script que deverá fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo.

Nota:

Você pode fazer o rc.subr(8) agir como se o knob fosse definido como ON, independentemente da sua configuração atual, prefixando o argumento para o script com one ou force, como em onestart ou forcestop. Tenha em mente que o force tem outros efeitos perigosos que mencionaremos abaixo, enquanto one apenas sobrescreve o knob ON/OFF. Por exemplo, suponha que dummy_enable seja OFF. O comando a seguir executará o método start apesar da configuração:

# /etc/rc.d/dummy onestart

4

Agora, a mensagem a ser mostrada no momento da inicialização não é mais codificada no script. Ela é especificada por uma variável do rc.conf(5) chamada dummy_msg. Este é um exemplo trivial de como as variáveis do rc.conf(5) podem controlar um script rc.d.

Importante:

Os nomes de todas as variáveis do rc.conf(5) usadas exclusivamente pelo nosso script devem possuir o mesmo prefixo: $ {name} _. Por exemplo: dummy_mode, dummy_state_file, e assim por diante.

Nota:

Embora seja possível usar um nome mais curto internamente, por exemplo, apenas msg, adicionar o prefixo exclusivo ${name}_ a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o nome das funções existentes no rc.subr(8).

Como regra, os scripts rc.d do sistema base não precisam fornecer valores padrões para as suas variáveis rc.conf(5) porque os padrões devem ser definidos em /etc/defaults/rc.conf. Por outro lado, os scripts rc.d para os ports devem fornecer os valores padrões, conforme mostrado no exemplo.

5

Aqui usamos dummy_msg para realmente controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função de shell é um exagero aqui, já que ele só executa um único comando; uma alternativa igualmente válida seria:

start_cmd="echo \"$dummy_msg\""

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.