The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect1/para
English
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.
1949/17850 · 1785
Context English Spanish State
_ translator-credits Aaron H Farias Martinez Timido@ubuntu.com, 2020
Practical rc.d scripting in BSD Scripting práctico rc.d en BSD
<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 es una marca registrada de FreeBSD Foundation.
NetBSD is a registered trademark of the NetBSD Foundation. NetBSD es una marca registrada de 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. Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se reclaman como marcas comerciales. Cuando esas designaciones aparecen en este documento, y el Proyecto FreeBSD conocía el reclamo de marca registrada, las designaciones han sido seguidas por el <quote>™</quote> o el <quote>®</quote> símbolo.
$FreeBSD: head/en_US.ISO8859-1/articles/rc-scripting/article.xml 44709 2014-04-29 21:39:27Z wblock $ $FreeBSD: head/en_US.ISO8859-1/articles/rc-scripting/article.xml 44709 2014-04-29 21:39:27Z wblock $
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>. Los principiantes pueden tener dificultades para relacionar los hechos de la documentación formal en el BSD <filename>rc.d</filename> marco con las tareas prácticas de <filename>rc.d</filename> secuencias de comandos. En este artículo, consideramos algunos casos típicos de complejidad creciente, mostrar <filename>rc.d</filename> características adecuadas para cada caso y comentar cómo funcionan. Dicho examen debe proporcionar puntos de referencia para un estudio más detallado del diseño y la aplicación eficiente de <filename>rc.d</filename>.
Introduction Introducción
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. El BSD histórico tenía un guión de inicio monolítico, <filename>/etc/rc</filename>.Fue invocado por <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> en el momento del arranque del sistema y realizó todas las tareas de la zona de usuario necesarias para la operación de múltiples usuarios: comprobar y montar sistemas de archivos, configurar la red, iniciar demonios, etc. La lista precisa de tareas no es la misma en todos los sistemas; los administradores necesitaban personalizarlo. Con pocas excepciones, <filename>/etc/rc</filename> tuvo que ser modificado, y a los verdaderos hackers les gustó.
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. El verdadero problema con el enfoque monolítico era que no proporcionaba control sobre los componentes individuales a partir de <filename>/etc/rc</filename>. Por ejemplo, <filename>/etc/rc</filename> no se pudo reiniciar un solo demonio. El administrador del sistema tuvo que encontrar el proceso del demonio a mano, matarlo, esperar hasta que realmente saliera y luego examinar <filename>/etc/rc</filename> para las banderas, y finalmente escriba la línea de comando completa para iniciar el demonio nuevamente. La tarea se volvería aún más difícil y propensa a errores si el servicio a reiniciar consistiera en más de un demonio o exigiera acciones adicionales. En pocas palabras, el único script no cumplió con el propósito de los scripts: facilitar la vida del administrador del sistema.
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. Más tarde hubo un intento de dividir algunas partes de <filename>/etc/rc</filename>con el fin de iniciar los subsistemas más importantes por separado. El ejemplo notorio fue <filename>/etc/netstart</filename>para sacar a relucir el networking. Permitió acceder a la red desde el modo de usuario único, pero no se integró bien en el proceso de inicio automático porque algunas partes de su código debían intercalarse con acciones esencialmente no relacionadas con la red. Por eso<filename>/etc/netstart</filename> mutado en <filename>/etc/rc.network</filename>. Este último ya no era un guión ordinario; se compone de grandes, enredados <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> funciones llamadas desde <filename>/etc/rc</filename> en diferentes etapas del inicio del sistema. Sin embargo, a medida que las tareas de inicio se volvieron diversas y sofisticadas, el <quote>quasi-modular</quote> enfoque se convirtió en un lastre incluso más que el monolítico <filename>/etc/rc</filename> había sido.
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. Sin un marco limpio y bien diseñado, los scripts de inicio tuvieron que hacer todo lo posible para satisfacer las necesidades de los sistemas operativos basados en BSD en rápido desarrollo. Por fin se hizo evidente que se necesitan más pasos en el camino hacia una estructura fina y extensible. <filename>rc</filename> sistema. Así BSD<filename>rc.d</filename> nació. Sus padres reconocidos fueron Luke Mewburn y la comunidad NetBSD. Posteriormente se importó a FreeBSD. Su nombre se refiere a la ubicación de los scripts del sistema para servicios individuales, que se encuentra en <filename>/etc/rc.d</filename>. Pronto conoceremos más componentes de la <filename>rc.d</filename> sistema y ver cómo se invocan los scripts individuales.
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. Las ideas básicas detrás de BSD <filename>rc.d</filename> son <emphasis>fina modularidad</emphasis> Y <emphasis>reutilización de código</emphasis>. <emphasis>Fina modularidad</emphasis> Significa que cada básico <quote>servicio</quote> como un demonio del sistema o una tarea de inicio primitiva, obtiene su propia <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script capaz de iniciar el servicio, detenerlo, recargarlo, verificar su estado. Una acción particular se elige mediante el argumento de la línea de comandos del script. los <filename>/etc/rc</filename> El script todavía impulsa el inicio del sistema, pero ahora simplemente invoca los scripts más pequeños uno por uno con el <option>start</option> argumento. También es fácil realizar tareas de apagado ejecutando el mismo conjunto de scripts con el <option>stop</option> argumento, que es hecho por <filename>/etc/rc.shutdown</filename>. Tenga en cuenta lo cerca que sigue la forma Unix de tener un conjunto de pequeñas herramientas especializadas, cada una cumpliendo su tarea lo mejor posible. <emphasis>Reutilización de código</emphasis> significa que las operaciones comunes se implementan como <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> funciones y recogidas en <filename>/etc/rc.subr</filename>. Ahora, un script típico puede tener solo unas pocas líneas de <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> código. Finalmente, una parte importante de la <filename>rc.d</filename> marco es <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, que ayuda <filename>/etc/rc</filename>para ejecutar los pequeños scripts de forma ordenada con respecto a las dependencias entre ellos. Puede ayudar <filename>/etc/rc.shutdown</filename>, también, porque el orden correcto para la secuencia de apagado es opuesto al de inicio.
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. El BSD <filename>rc.d</filename> el diseño se describe en <link linkend="lukem">el artículo original de Luke Mewburn</link>, y el <filename>rc.d</filename> Los componentes están documentados con gran detalle en <link linkend="manpages">las respectivas páginas del manual</link>.Sin embargo, puede que no parezca obvio para un <filename>rc.d</filename> novato cómo unir las numerosas partes y piezas para crear un guión con estilo para una tarea en particular. Por lo tanto, este artículo intentará un enfoque diferente para describir <filename>rc.d</filename>.Mostrará qué funciones deben usarse en varios casos típicos y por qué. Tenga en cuenta que este no es un documento de instrucciones porque nuestro objetivo no es dar recetas listas para usar, sino mostrar algunas entradas fáciles al <filename>rc.d</filename> reino. Este artículo tampoco sustituye a las páginas del manual correspondientes. No dude en consultarlos para obtener documentación más formal y completa mientras lee este artículo.
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>. Hay requisitos previos para comprender este artículo. En primer lugar, debe estar familiarizado con el <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> lenguaje de secuencias de comandos para dominar <filename>rc.d</filename>. Además, debe saber cómo realiza el sistema las tareas de inicio y apagado del área de usuario, que se describe en <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 artículo se centra en la rama FreeBSD de <filename>rc.d</filename>. Sin embargo, también puede ser útil para los desarrolladores de NetBSD, porque las dos ramas de BSD <filename>rc.d</filename> no solo comparten el mismo diseño, sino que también son similares en sus aspectos visibles para los autores de guiones.
Outlining the task Delineando la tarea
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: Un poco de consideración antes de empezar <envar>$EDITOR</envar> no Dolera. Para escribir un buen temperamento <filename>rc.d</filename> script para un servicio del sistema, deberíamos poder responder las siguientes preguntas primero:
Is the service mandatory or optional? ¿El servicio es obligatorio u opcional?
Will the script serve a single program, e.g., a daemon, or perform more complex actions? ¿El script servirá a un solo programa, por ejemplo, un demonio, o realizará acciones más complejas?
Which other services will our service depend on, and vice versa? ¿De qué otros servicios dependerá nuestro servicio y viceversa?
From the examples that follow we will see why it is important to know the answers to these questions. De los ejemplos que siguen veremos por qué es importante conocer las respuestas a estas preguntas.
A dummy script Un guión ficticio
The following script just emits a message each time the system boots up: El siguiente script simplemente emite un mensaje cada vez que se inicia el sistema:
#!/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: Las cosas a tener en cuenta son:
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: Un guión interpretado debe comenzar con la magia <quote>shebang</quote> línea. Esa línea especifica el programa intérprete del guión. Debido a la línea shebang, el script puede invocarse exactamente como un programa binario siempre que tenga el bit de ejecución establecido. (Ver <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) Por ejemplo, un administrador del sistema puede ejecutar nuestro script manualmente, desde la línea de comando:
<prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput> <prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput>

Loading…

User avatar Aaron

New translation

FreeBSD Doc (Archived) / articles_rc-scripting — Spanish

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.
Las ideas básicas detrás de BSD <filename>rc.d</filename> son <emphasis>fina modularidad</emphasis> Y <emphasis>reutilización de código</emphasis>. <emphasis>Fina modularidad</emphasis> Significa que cada básico <quote>servicio</quote> como un demonio del sistema o una tarea de inicio primitiva, obtiene su propia <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script capaz de iniciar el servicio, detenerlo, recargarlo, verificar su estado. Una acción particular se elige mediante el argumento de la línea de comandos del script. los <filename>/etc/rc</filename> El script todavía impulsa el inicio del sistema, pero ahora simplemente invoca los scripts más pequeños uno por uno con el <option>start</option> argumento. También es fácil realizar tareas de apagado ejecutando el mismo conjunto de scripts con el <option>stop</option> argumento, que es hecho por <filename>/etc/rc.shutdown</filename>. Tenga en cuenta lo cerca que sigue la forma Unix de tener un conjunto de pequeñas herramientas especializadas, cada una cumpliendo su tarea lo mejor posible. <emphasis>Reutilización de código</emphasis> significa que las operaciones comunes se implementan como <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> funciones y recogidas en <filename>/etc/rc.subr</filename>. Ahora, un script típico puede tener solo unas pocas líneas de <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> código. Finalmente, una parte importante de la <filename>rc.d</filename> marco es <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, que ayuda <filename>/etc/rc</filename>para ejecutar los pequeños scripts de forma ordenada con respecto a las dependencias entre ellos. Puede ayudar <filename>/etc/rc.shutdown</filename>, también, porque el orden correcto para la secuencia de apagado es opuesto al de inicio.
2 months ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:107
String age
3 months ago
Source string age
a year ago
Translation file
articles/es/rc-scripting.po, string 16