Gentoo Logo

Renuncia de responsabilidad: Este manual ha sido sustituido por una versión más reciente y no tendrá soporte de aquí en adelante.


[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


4. Initscripts

Contenido:

4.a. Niveles de ejecución

Iniciando su sistema

Al iniciar, notará que pasará al frente suyo una gran cantidad de texto. Si pone atención, notará que estos textos son iguales cada vez que reinicie su sistema. La secuencia de todas estas acciones se llama la secuencia de inicio y es (más o menos) definido estáticamente.

Primero, su gestor de arranque cargará a la memoria la imagen del kernel que definido en la configuración del gestor de arranque, después de lo cual, se indica a la CPU que debe ejecutar el kernel. Al ser cargado y luego ejecutado inicializa todas las estructuras y tareas específicas del kernel e inicia el proceso init.

Este proceso asegura que todos los sistemas de archivo (definidos en /etc/fstab) estén montados y listos para usar. Luego ejecuta varios scripts en /etc/init.d, correspondientes a los servicios requeridos para tener un sistema correctamente iniciado.

Finalmente, al concluir la ejecución de los scripts, init activa los terminales (generalmente solo las consolas virtuales accesibles con Alt-F1, Alt-F2, etc.) fijándoles un proceso especial denominado agetty. Este proceso hará posible que pueda ingresar al sistema a través de uno de estos terminales ejecutando login.

Scripts de inicio (init scripts)

Ahora bien, init no solamente ejecuta los scripts contenidos en /etc/init.d de manera aleatoria. Aún más, no ejecuta todos los scripts del /etc/init.d, solamente los que han sido seleccionados para ejecutar. Los scripts seleccionados para ejecutar se encuentran dentro del directorio /etc/runlevels.

Primero, init ejecuta todos los scripts de /etc/init.d cuyos vínculos simbólicos se encuentran dentro de /etc/runlevels/boot. Usualmente los iniciará en orden alfabético, pero algunos scripts tienen información relativa a dependencias, para lo cual otros scripts deben ser iniciados anteriormente.

Cuando todos los scripts referenciados en /etc/runlevels/boot sean ejecutados, init continua su trabajo con los scripts en /etc/runlevels/default. Una vez más, usará el orden alfabético, salvo cuando hay dependencias, en cuyo caso es alterado el orden de inicio para realizar una secuencia válida de arranque.

¿Cómo funciona Init?

Por supuesto que init no decide todo eso por su cuenta. Requiere un archivo de configuración que especifica las acciones a tomar. Este archivo es /etc/inittab.

Si recuerda al secuencia de inicio recién explicada, recordará que la primera acción de init es montar todos los sistemas de archivo. Esto está definido en la siguiente línea de /etc/inittab:

Listado de Código 1.1: La línea de inicialización del sistema en /etc/inittab

si::sysinit:/sbin/rc sysinit

Es línea dice a init que debe ejecutar /sbin/rc sysinit al iniciar el sistema. Los scripts /sbin/rc se encargan de la inicialización, con lo que podríamos decir que init no hace mucho, delega la tarea de inicialización del sistema a otro proceso.

En segundo lugar, init ejecutó los scripts con vínculos simbólicos en /etc/runlevels/boot. Esto se define en la siguiente línea:

Listado de Código 1.2: Inicialización del sistema, continuada

rc::bootwait:/sbin/rc boot

Una vez más, el script rc lleva a cabo las tareas necesarias. Note que la opción de rc (boot) corresponde al subdirectorio usado bajo /etc/runlevels.

Ahora init revisa su archivo de configuración para ver que nivel de ejecución debe ejecutar. Para decidirlo, lee la siguiente línea de /etc/inittab:

Listado de Código 1.3: La línea init por defecto (default)

id:3:initdefault:

En este caso (para la mayoría de usuarios Gentoo), el identificador del nivel de ejecución será el 3. Con esta información init revisa qué debe ejecutar para iniciar el nivel de ejecución 3:

Listado de Código 1.4: Definiciones de niveles de ejecución

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

La línea que define el nivel 3, de nuevo usa el script rc para iniciar los servicios (ahora con el parámetro por defecto default). Note una vez más que el parámetro pasado al script rc corresponde al subdirectorio de /etc/runlevels.

Al terminar rc, init decide cuáles consolas virtuales debe activar y qué comandos deben ser ejecutados para cada una:

Listado de Código 1.5: Definición de las consolas virtuales

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

¿Qué es un nivel de ejecución?

Ha visto que init utiliza un esquema de numeración para decidir cual nivel de ejecución debe activar. Un nivel de ejecución es un estado en el cual su sistema está corriendo y contiene scripts (del nivel de ejecución o initscripts) que serán ejecutados al ingresar o salir del nivel de ejecución.

En Gentoo, hay siete niveles de ejecución definidos: tres internos y cuatro definidos por el usuario. Los internos se llaman sysinit, shutdown y reboot y hacen exactamente lo que implican sus nombres, inicialización, apagado y reinicio del sistema.

Los niveles de ejecución definidos por el usuario están acompañados de un subdirectorio bajo /etc/runlevels: boot, default, nonetwork y single. El nivel de ejecución boot inicia los servicios necesarios que requieren los demás niveles de ejecución. Los tres niveles de ejecución restantes difieren respecto a los servicios que inician: default es para uso diario, nonetwork en caso de no requerirse la red y single es utilizado en caso de necesitar arreglar el sistema.

Trabajando con los scripts de inicio

Los scripts iniciados por el proceso rc son llamados scripts de inicio o init scripts. Cada script en /etc/init.d puede ser ejecutado con los parámetros start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme o broken.

Para iniciar, parar o reiniciar un servicio (y sus respectivas dependencias), deben usarse start, stop y restart:

Listado de Código 1.6: Iniciando postfix

# /etc/init.d/postfix start

Nota: Sólo los servicios que necesiten (need) del servicio nombrado serán parados o reiniciados. Los demás servicios, aquellos que usen (use) el servicio nombrado, pero que no lo necesiten (need) continuarán sin ser tocados.

Si desea parar un servicio, pero no los que dependan de el, puede usar el parámetro para pausarlo pause:

Listado de Código 1.7: Parando postfix, manteniendo ejecución de los demás servicios

# /etc/init.d/postfix pause

Si desea ver el estado de un servicio (iniciado, parado, pausado, ...) puede usar el parámetro status:

Listado de Código 1.8: Estado del servicio postfix

# /etc/init.d/postfix status

Si la respuesta a status indica que el servicio está corriendo, pero realmente no es así, puede reajustarlo manualmente con el parámetro zap:

Listado de Código 1.9: Reajustando la información del estado del servicio postfix

# /etc/init.d/postfix zap

Para preguntar por las dependencias que tiene un servicio, puede usar iuse o ineed. Con ineed puede ver cuales servicios son realmente necesarios para el correcto funcionamiento del servicio nombrado. Por otra parte, el parámetro iuse muestra los servicios que pueden ser usados por el servicio nombrado, pero que no son requeridos para su correcto funcionamiento.

Listado de Código 1.10: Solicitando una lista de servicios de los cuales depende postfix

# /etc/init.d/postfix ineed

De igual manera, puede indagar que servicios requieren el servicio nombrado (needsme) o cuáles pueden usarlo (usesme):

Listado de Código 1.11: Solicitando una lista de todos los servicios que requieren postfix

# /etc/init.d/postfix needsme

Finalmente, puede indagar cuales dependencias son requeridas y están faltando:

Listado de Código 1.12: Solicitando una lista de dependencias faltantes para postfix

# /etc/init.d/postfix broken

4.b. Trabajando con rc-update

¿Qué es rc-update?

El sistema de inicio (init) de Gentoo usa un árbol de dependencias para decidir qué servicios deben iniciarse primero. Como ésta es una tarea tediosa, que no deseamos que nuestros usuarios tengan que hacer manualmente, hemos creado unas herramientas para facilitar la administración de los niveles de ejecución y los scripts de inicio.

Con rc-update puede añadir o quitar scripts de inicio a un nivel de ejecución. La herramienta rc-update automáticamente usará el script depscan.sh para reconstruir el árbol de dependencias.

Añadiendo y removiendo servicios

Ya hemos agregado scripts de inicio al nivel de ejecución por defecto durante la instalación de Gentoo. En ese instante tal vez no haya tenido una idea clara acerca del uso de un nivel de ejecución "por defecto", aunque ahora sí. El script rc-update requiere un segundo parámetro que define la acción a llevar a cabo: add, del o show para agregar, borrar o mostrar.

Para añadir o quitar un script de inicio, use rc-update con el parámetro add o del, seguido por el nombre del script de inicio y el nivel de ejecución, por ejemplo:

Listado de Código 2.1: Quitar postfix del nivel de ejecución por defecto

# rc-update del postfix default

El comando rc-update show mostrará todos los scripts de inicio con los niveles de ejecución donde ejecutarán:

Listado de Código 2.2: Recibiendo información de los scripts de inicio

# rc-update show

4.c. Configuración de servicios

¿Porqué requerimos configuración adicional?

Los scripts de inicio pueden ser bastante complejos, por lo cual no es interesante que los usuarios modifiquen directamente el script de inicio, ya que esto puede ser propenso a errores. Sin embargo es importante poder configurar estos servicios, en caso que se quieren dar más opciones al servicio.

Una segunda razón para mantener esta información fuera del script de inicio es para poder actualizar estos scripts sin que los cambios de configuración sean perdidos.

El directorio /etc/conf.d

Gentoo provee una manera fácil de configurar estos servicios: cada script de inicio configurable tiene un archivo dispuesto en /etc/conf.d. Por ejemplo, el script de inicio apache2 (llamado /etc/init.d/apache2) tiene un archivo de configuración de nombre /etc/conf.d/apache2, el cual contiene las opciones a pasar al servidor web Apache 2 en el momento de inicio:

Listado de Código 3.1: Variables definidas en /etc/conf.d/apache2

APACHE2_OPTS="-D PHP4"

Este tipo de archivo de configuración contiene solamente variables (como /etc/make.conf), lo que facilita la configuración de servicios. También nos permite suministrar información adicional acerca de las variables (en forma de comentarios).

4.d. Escribiendo scripts de inicio

¿Realmente tengo que hacerlo?

Realmente, no. Escribir un script de inicio usualmente no hace falta, ya que Gentoo provee scripts listos para usar para todos los servicios suministrados. Sin embargo, puede haber instalado un servicio sin usar Portage, en cuyo caso probablemente tenga que crear un script de inicio.

No use el script de inicio suministrado por el servicio si no está explícitamente escrito para Gentoo: los scripts de inicio de Gentoo ¡no son compatibles con los de las demás distribuciones!

Disposición

La disposición básica de un script de inicio se muestra a continuación.

Listado de Código 4.1: Disposición básica de un script de inicio

#!/sbin/runscript

depend() {
  (Información acerca de las dependencias)
}

start() {
  (Comandos requeridos para iniciar el servicio)
}

stop() {
  (Comandos requeridos para parar el servicio)
}

restart() {
  (Comandos requeridos para reiniciar el servicio)
}

Cualquier script de inicio requiere la definición de la función start(). Todas las demás son opcionales.

Dependencias

Hay dos dependencias que puede definir: use y need. Tal como hemos mencionado anteriormente, la dependencia need es más estricta que la dependencia use. Siguiendo este esquema, se declaran los servicios que dependen de éste o la dependencia virtual.

Una dependencia virtual es una suministrada por un servicio, pero no solo por ese servicio. Su script de inicio puede depender de un gestor de registro de sistema, habiendo disponibilidad de varios (metalogd, syslog-ng, sysklogd, ...). Como no se necesitan todos (ningún sistema normal tiene todos estos gestores de registro instalados y corriendo) nos aseguramos que todos estos servicios provean una dependencia virtual.

Examinemos la información de dependencia del servicio postfix.

Listado de Código 4.2: Información de dependencias de postfix

depend() {
  need net
  use logger dns
  provide mta
}

Como podemos ver, el servicio postfix:

  • requiere la dependencia (virtual) net (suministrada por, en este caso, /etc/init.d/net.eth0)
  • usa la dependencia (virtual) logger (suministrada por, en este caso, /etc/init.d/syslog-ng)
  • usa la dependencia virtual (virtual) dns (suministrada por, en este caso, /etc/init.d/named)
  • provee la dependencia (virtual) mta (común a todos los servidores de correo electrónico)

Controlando el orden

En algunos casos, tal vez no requiera un servicio determinado, pero desea que inicie antes (o después) de otro servicio si está disponible en el sistema (note la condicionalidad, esto ya no es una dependencia) y en el mismo nivel de ejecución (note la condicionalidad, solo involucra servicios del mismo nivel de ejecución). Puede suministrar esta información usando los parámetros before o after.

Como ejemplo, podemos ver la disposición del servicio portmap:

Listado de Código 4.3: La función depend() en el servicio portmap

depend() {
  need net
  before inetd
  before xinetd
}

También puede usar el carácter cque engloba "*" para todos los servicios, aunque no es aconsejable.

Listado de Código 4.4: Ejecutando un script de inicio como el primer script del nivel de ejecución

depend() {
  before *
}

Funciones estándar

Junto con la función depend(), hará falta definir la función start(), que contiene los comandos necesarios para inicializar su servicio. Es aconsejable usar las funciones ebegin y eend para informarle al usuario acerca de lo que está ocurriendo:

Listado de Código 4.5: Ejemplo de función start()

start() {
  ebegin "Starting my_service"
  start-stop-daemon --start --quiet --exec /path/to/my_service
  eend $?
}

Si requiere más ejemplos de funciones start(), favor leer directamente las fuentes de los scripts de inicio en su directorio /etc/init.d. En lo que respecta el start-stop-daemon, hay un excelente página man disponible en caso de requerir mayor información:

Listado de Código 4.6: Buscando página man para el start-stop-daemon

# man start-stop-daemon

Otras funciones que puede definir son: stop() y restart(). ¡No es obligatorio definirlas! Nuestro sistema de inicio es suficientemente inteligente para llevar a cabo esta funciones solo, si usa el start-stop-daemon.

Añadiendo opciones personalizadas

Si desea que su script de inicio soporte un mayor número de opciones de las que hemos encontrado hasta ahora, debe agregar la opción a la variable opts y crear una función con el mismo nombre de la opción. Por ejemplo, para soportar una opción de nombre restartdelay:

Listado de Código 4.7: Soporte para la opción restartdelay

opts="${opts} restartdelay"

restartdelay() {
  stop()
  sleep 3    # Espere 3 segundo antes de reiniciar
  start()
}

Variables para la configuración de servicios

No hay que hacer nada para soportar un archivo de configuración en /etc/conf.d: si su script de inicio se ejecuta, los siguientes archivos serán automáticamente leídos (sourced) y las variables estarán disponibles para usar.

  • /etc/conf.d/<your init script>
  • /etc/conf.d/basic
  • /etc/rc.conf

También, si su script de inicio provee una dependencia virtual (como net), el archivo asociado a esa dependencia (el /etc/conf.d/net) será leído también.

4.e. Cambiando el comportamiento del nivel de ejecución

¿Quién puede beneficiarse de esto?

Muchos usuarios de equipos portátiles conocen la situación: en casa necesita iniciar net.eth0 mientras que puede no querer iniciar net.eth0 mientras está de viaja (cuando no hay una red disponible). Con Gentoo puede modificar el comportamiento del nivel de ejecución para sus propios propósitos.

Por ejemplo puede crear un segundo nivel de ejecución "default" con el cual puede arrancar y que utiliza otros scripts de inicio que le han sido asignados. Puede seleccionar al arrancar que nivel de ejecución quiere utilizar.

Utilizando SOFTLEVEL

Antes de nada, cree el directorio para su segundo nivel de ejecución "default". Como ejemplo vamos a crear el nivel de ejecución offline:

Listado de Código 5.1: Creando el directorio para el nivel de ejecución

# mkdir /etc/runlevels/offline

Añada los scripts de inicio necesarios para el nuevo nivel de ejecución. Por ejemplo, si quiere una copia exacta de su actual "default" pero sin net.eth0:

Listado de Código 5.2: Añadiendo los scripts de inicio necesarios

# ls /etc/runlevels/default
acpid  domainname  local  net.eth0  netmount  postfix  syslog-ng  vixie-cron
# rc-update add acpid offline
# rc-update add domainname offline
# rc-update add local offline
# rc-update add syslog-ng offline
# rc-update add vixie-cron offline

Ahora edite la configuración de su gestor de arranca y añada una nueva entrada para el nivel de ejecución offline. Por ejemplo, en /boot/grub/grub.conf:

Listado de Código 5.3: Añadiendo una entrada para el nivel de ejecución offline

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Listo, ha terminado de configurarlo. Si arranca su sistema y selecciona la nueva entrada al inicio, el nivel de ejecución offline será el utilizado en lugar del default.

Utilizando BOOTLEVEL

Utilizar bootlevel es completamente análogo a softlevel. La única diferencia es que se define un segundo nivel de ejecución "boot" en lugar de un segundo "default".


[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


Imprimir

Ver completo

Página actualizada 2 de noviembre, 2004

Esta traducción ha dejado de tener soporte

Sumario: Gentoo uses a special initscript format which, amongst other features, allows dependency-driven decisions and virtual initscripts. This chapter explains all these aspects and explains how to deal with these scripts.

Sven Vermeulen
Author

Daniel Robbins
Author

Chris Houser
Author

Jerry Alexandratos
Author

Seemant Kulleen
Gentoo x86 Developer

Tavis Ormandy
Gentoo Alpha Developer

Jason Huebel
Gentoo AMD64 Developer

Guy Martin
Gentoo HPPA developer

Pieter Van den Abeele
Gentoo PPC developer

Joe Kallar
Gentoo SPARC developer

John P. Davis
Editor

Pierre-Henri Jondot
Editor

Eric Stockbridge
Editor

Rajiv Manglani
Editor

Jungmin Seo
Editor

Stoyan Zhekov
Editor

Jared Hudson
Editor

Colin Morey
Editor

Jorge Paulo
Editor

Carl Anderson
Editor

Jon Portnoy
Editor

Zack Gilburd
Editor

Jack Morgan
Editor

Benny Chuang
Editor

Erwin
Editor

Joshua Kinard
Editor

Tobias Scherbaum
Editor

Lars Weiler
Editor

Jochen Maes
Editor

Grant Goodyear
Reviewer

Gerald J. Normandin Jr.
Reviewer

Donnie Berkholz
Reviewer

Ken Nowack
Reviewer

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.