Translation

(itstool) path: sect1/para
There are prerequisites to understanding this article. First of all, you should be familiar with the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> scripting language in order to master <filename>rc.d</filename>. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
476/4520
Context English Portuguese (Brazil) State
<email>yar@FreeBSD.org</email> <email>yar@FreeBSD.org</email>
<personname><firstname>Yar</firstname><surname>Tikhiy</surname></personname><affiliation> <_:address-1/> </affiliation> <personname><firstname>Yar</firstname><surname>Tikhiy</surname></personname><affiliation> <_:address-1/> </affiliation>
<year>2005</year> <year>2006</year> <year>2012</year> <holder>The FreeBSD Project</holder> <year>2005</year> <year>2006</year> <year>2012</year> <holder>The FreeBSD Project</holder>
FreeBSD is a registered trademark of the FreeBSD Foundation. FreeBSD is a registered trademark of the FreeBSD Foundation.
NetBSD is a registered trademark of the NetBSD Foundation. NetBSD is a registered trademark of the NetBSD Foundation.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol.
$FreeBSD: head/en_US.ISO8859-1/articles/rc-scripting/article.xml 44709 2014-04-29 21:39:27Z wblock $ $FreeBSD: head/pt_BR.ISO8859-1/articles/rc-scripting/pt_BR.po 52247 2018-09-12 00:52:17Z ebrandi $
Beginners may find it difficult to relate the facts from the formal documentation on the BSD <filename>rc.d</filename> framework with the practical tasks of <filename>rc.d</filename> scripting. In this article, we consider a few typical cases of increasing complexity, show <filename>rc.d</filename> features suited for each case, and discuss how they work. Such an examination should provide reference points for further study of the design and efficient application of <filename>rc.d</filename>. Os iniciantes podem achar difícil relacionar os fatos da documentação formal do framework <filename>rc.d</filename> do BSD com as tarefas práticas do script <filename>rc.d</filename>. Neste artigo, consideramos alguns casos típicos de complexidade crescente, vamos mostrar os recursos do <filename>rc.d</filename> adequados para cada caso e vamos discutir como eles funcionam. Esse exame deve fornecer pontos de referência para um estudo mais aprofundado do design e da aplicação eficiente do <filename>rc.d</filename>.
Introduction Introdução
The historical BSD had a monolithic startup script, <filename>/etc/rc</filename>. It was invoked by <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> at system boot time and performed all userland tasks required for multi-user operation: checking and mounting file systems, setting up the network, starting daemons, and so on. The precise list of tasks was not the same in every system; admins needed to customize it. With few exceptions, <filename>/etc/rc</filename> had to be modified, and true hackers liked it. Historicamente o BSD tinha um script de inicialização monolítico, o <filename>/etc/rc</filename>. Ele era chamado pelo <citerefentry><refentrytitle>init</refentrytitle><manvolnum> 8</manvolnum></citerefentry> 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 <filename>/etc/rc</filename> teve que ser modificado, e os verdadeiros hackers gostaram disso.
The real problem with the monolithic approach was that it provided no control over the individual components started from <filename>/etc/rc</filename>. For instance, <filename>/etc/rc</filename> could not restart a single daemon. The system admin had to find the daemon process by hand, kill it, wait until it actually exited, then browse through <filename>/etc/rc</filename> for the flags, and finally type the full command line to start the daemon again. The task would become even more difficult and prone to errors if the service to restart consisted of more than one daemon or demanded additional actions. In a few words, the single script failed to fulfil what scripts are for: to make the system admin's life easier. O problema real com a abordagem monolítica era que ela não fornecia nenhum controle sobre os componentes individuais iniciados a partir do <filename>/etc/rc</filename>. Por exemplo, o <filename>/etc/rc</filename> 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 <filename>/etc/rc</filename>, 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.
Later there was an attempt to split out some parts of <filename>/etc/rc</filename> for the sake of starting the most important subsystems separately. The notorious example was <filename>/etc/netstart</filename> to bring up networking. It did allow for accessing the network from single-user mode, but it did not integrate well into the automatic startup process because parts of its code needed to interleave with actions essentially unrelated to networking. That was why <filename>/etc/netstart</filename> mutated into <filename>/etc/rc.network</filename>. The latter was no longer an ordinary script; it comprised of large, tangled <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions called from <filename>/etc/rc</filename> at different stages of system startup. However, as the startup tasks grew diverse and sophisticated, the <quote>quasi-modular</quote> approach became even more of a drag than the monolithic <filename>/etc/rc</filename> had been. Mais tarde, houve uma tentativa de dividir algumas partes do <filename>/etc/rc</filename> para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o <filename>/etc/netstart</filename> 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 <filename>/etc/netstart</filename> mudou para <filename>/etc/rc.network</filename>. Este último não era mais um script comum; ele era composto por um emaranhado de funções <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> chamadas pelo <filename>/etc/rc</filename> 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 <quote>quase modular</quote> tornou-se ainda mais engessada do que o monolítico <filename>/etc/rc</filename>.
Without a clean and well-designed framework, the startup scripts had to bend over backwards to satisfy the needs of rapidly developing BSD-based operating systems. It became obvious at last that more steps are necessary on the way to a fine-grained and extensible <filename>rc</filename> system. Thus BSD <filename>rc.d</filename> was born. Its acknowledged fathers were Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. Its name refers to the location of system scripts for individual services, which is in <filename>/etc/rc.d</filename>. Soon we will learn about more components of the <filename>rc.d</filename> system and see how the individual scripts are invoked. 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 <filename>rc</filename> extensível e customizável. Assim nasceu o BSD <filename>rc.d</filename>. 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 <filename>/etc/rc.d</filename>. Em breve, vamos aprender sobre mais componentes do sistema <filename>rc.d</filename> e vamos ver como os scripts individuais são invocados.
The basic ideas behind BSD <filename>rc.d</filename> are <emphasis>fine modularity</emphasis> and <emphasis>code reuse</emphasis>. <emphasis>Fine modularity</emphasis> means that each basic <quote>service</quote> such as a system daemon or primitive startup task gets its own <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script able to start the service, stop it, reload it, check its status. A particular action is chosen by the command-line argument to the script. The <filename>/etc/rc</filename> script still drives system startup, but now it merely invokes the smaller scripts one by one with the <option>start</option> argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the <option>stop</option> argument, which is done by <filename>/etc/rc.shutdown</filename>. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. <emphasis>Code reuse</emphasis> means that common operations are implemented as <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions and collected in <filename>/etc/rc.subr</filename>. Now a typical script can be just a few lines' worth of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> code. Finally, an important part of the <filename>rc.d</filename> framework is <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which helps <filename>/etc/rc</filename> to run the small scripts orderly with respect to dependencies between them. It can help <filename>/etc/rc.shutdown</filename>, too, because the proper order for the shutdown sequence is opposite to that of startup. As idéias básicas por trás do BSD <filename>rc.d</filename> são <emphasis>modularidade fina</emphasis> e <emphasis>reutilização de código</emphasis>. <emphasis>Modularidade fina</emphasis> significa que cada <quote>serviço básico</quote>, como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script <citerefentry><refentrytitle>sh</refentrytitle> <manvolnum></manvolnum></citerefentry> 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 <filename>/etc/rc</filename> ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento <option>start</option>. É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento <option>stop</option>, o que é feito pelo <filename>/etc/rc.shutdown</filename>. 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. <emphasis>Reutilização de código</emphasis> significa que operações comuns são implementadas como funções <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> e coletadas em <filename>/etc/rc.subr </filename>. Agora, um script típico pode conter apenas algumas linhas de código <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum> </citerefentry>. Finalmente, uma parte importante do framework do <filename>rc.d</filename> é <citerefentry> <refentrytitle>rcorder</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>, o qual ajuda o <filename>/etc/rc</filename> a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o <filename>/etc/rc.shutdown</filename>, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização.
The BSD <filename>rc.d</filename> design is described in <link linkend="lukem">the original article by Luke Mewburn</link>, and the <filename>rc.d</filename> components are documented in great detail in <link linkend="manpages">the respective manual pages</link>. However, it might not appear obvious to an <filename>rc.d</filename> newbie how to tie the numerous bits and pieces together in order to create a well-styled script for a particular task. Therefore this article will try a different approach to describe <filename>rc.d</filename>. It will show which features should be used in a number of typical cases, and why. Note that this is not a how-to document because our aim is not at giving ready-made recipes, but at showing a few easy entrances into the <filename>rc.d</filename> realm. Neither is this article a replacement for the relevant manual pages. Do not hesitate to refer to them for more formal and complete documentation while reading this article. O design do BSD <filename>rc.d</filename> é descrito no <link linkend="lukem">artigo original de Luke Mewburn</link>, e os componentes do <filename>rc.d</filename> são documentados em grande detalhe nas <link linkend="manpages">respectivas páginas de manual</link>. No entanto, pode não parecer óbvio para um novato em <filename>rc.d</filename> 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 <filename>rc.d</filename>. 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 <filename>rc.d</filename>. 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.
There are prerequisites to understanding this article. First of all, you should be familiar with the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> scripting language in order to master <filename>rc.d</filename>. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> para poder dominar o <filename>rc.d</filename>. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
This article focuses on the FreeBSD branch of <filename>rc.d</filename>. Nevertheless, it may be useful to NetBSD developers, too, because the two branches of BSD <filename>rc.d</filename> not only share the same design but also stay similar in their aspects visible to script authors. Este artigo foca no branch <filename>rc.d</filename> do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs <filename>rc.d</filename> do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script.
Outlining the task Esboçando a tarefa
A little consideration before starting <envar>$EDITOR</envar> will not hurt. In order to write a well-tempered <filename>rc.d</filename> script for a system service, we should be able to answer the following questions first: Um pouco de consideração antes de iniciar o <envar>$EDITOR</envar> não irá prejudicar. Para escrever um script <filename>rc.d</filename> corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro:
Is the service mandatory or optional? O serviço é obrigatório ou opcional?
Will the script serve a single program, e.g., a daemon, or perform more complex actions? O script servirá um único programa, por exemplo, um daemon, ou realizará ações mais complexas?
Which other services will our service depend on, and vice versa? De quais outros serviços nosso serviço dependerá e vice-versa?
From the examples that follow we will see why it is important to know the answers to these questions. A partir dos exemplos que se seguem, veremos o porque é importante conhecer as respostas a essas perguntas.
A dummy script Um script fictício
The following script just emits a message each time the system boots up: O script a seguir apenas emite uma mensagem toda vez que o sistema é inicializado:
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
Things to note are: Os pontos a serem observadas são:
An interpreted script should begin with the magic <quote>shebang</quote> line. That line specifies the interpreter program for the script. Due to the shebang line, the script can be invoked exactly like a binary program provided that it has the execute bit set. (See <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) For example, a system admin can run our script manually, from the command line: Um script interpretado deve começar com a linha mágica <quote>shebang</quote>. Essa linha especifica o programa interpretador para o script. Devido a linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando:
<prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput> <prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput>
In order to be properly managed by the <filename>rc.d</filename> framework, its scripts need to be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language. If you have a service or port that uses a binary control utility or a startup routine written in another language, install that element in <filename>/usr/sbin</filename> (for the system) or <filename>/usr/local/sbin</filename> (for ports) and call it from a <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script in the appropriate <filename>rc.d</filename> directory. Para ser adequadamente gerenciado pelo framework do <filename>rc.d</filename>, seus scripts precisam ser escritos na linguagem <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Se você tiver um serviço ou port que use um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale este elemento em <filename>/usr/sbin</filename> (para o sistema) ou em <filename>/usr/local/sbin</filename> (para um port) e invoque-o por meio de um script <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> no diretório apropriado do <filename>rc.d</filename>.
If you would like to learn the details of why <filename>rc.d</filename> scripts must be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language, see how <filename>/etc/rc</filename> invokes them by means of <function>run_rc_script</function>, then study the implementation of <function>run_rc_script</function> in <filename>/etc/rc.subr</filename>. Caso você queira aprender os detalhes do porque os scripts <filename>rc.d</filename> devem ser escritos na linguagem <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, veja como o <filename>/etc/rc</filename> invoca-os por meio de <function>run_rc_script</function>, e então estude a implementação de <function>run_rc_script</function> em <filename>/etc/rc. subr</filename>.

Loading…

New source string a year ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:151
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/rc-scripting.po, string 18