Manual:AMD64/Trabajao/GuionesInicio

Manual AMD64
Instalación
Acerca de la instalación
Elegir los medios
Configurar la red
Preparar los discos
Instalar el stage3
Instalar el sistema base
Configurar el núcleo
Configurar el sistema
Instalar las herramientas
Configurar el cargador de arranque
Terminar
Trabajar con Gentoo
Introducción a Portage
Ajustes USE
Características de Portage
Sistema de guiones de inicio
Variables de entorno
Trabajar con Portage
Ficheros y directorios
Variables
Mezclar ramas de software
Herramientas adicionales
Repositorios personalizados de paquetes
Características avanzadas
Configuración de la red
Comenzar
Configuración avanzada
Configuración de red modular
Conexión inalámbrica
Añadir funcionalidad
Gestión dinámica

Importante
El contenido de esta página no se aplica a los usuarios que eligieron un perfil systemd en Elegir el perfil correcto.

Niveles de ejecución

Iniciando el sistema

Al iniciar, notará que pasará al frente suyo una gran cantidad de texto. Si pone atención, notará que estos textos son (normalmente) 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.

En primer lugar, su gestor de arranque cargará en memoria la imagen del núcleo que definió en la configuración del gestor de arranque, después de lo cual, se indica a la CPU que ejecute el núcleo. Al ser cargado y luego ejecutado inicializa todas las estructuras y tareas específicas del núcleo y comienza el proceso de inicio.

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

Finalmente, una vez ejecutados todos los guiones, inicio activa las consolas virtuales accesibles mediante Ctrl+Alt+ F1, Ctrl+Alt + F2, etc., asociando a cada una un proceso especial llamado agetty. Este proceso garantiza que los usuarios puedan iniciar sesión mediante login.

Guiones de inicio

Los guiones en /etc/init.d/ no se ejecutan aleatoriamente. Inicio no ejecuta todos los guiones en /etc/init.d/, solo los que se le indica que ejecute, a través de /etc/runlevels/.

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

Una vez ejecutados todos los guiones referenciados en /etc/runlevels/boot/, inicio ejecutará los guiones enlazados en /etc/runlevels/default/. De nuevo, usará el orden alfabético para decidir qué guiones ejecutar primero, a menos que un guión contenga información de dependencia, en cuyo caso se modifica el orden para proporcionar una secuencia de inicio válida. Por este motivo, los comandos utilizados durante la instalación de Gentoo Linux usan el nivel de ejecución predeterminado (p. ej., rc-update add sshd default).

¿Cómo funciona init?

Por supuesto que inicio no decide todo eso por su cuenta. Requiere un archivo de configuración que especifica las acciones a tomar. Este archivo es /etc/inittab. Inicio utiliza el archivo /etc/inittab para determinar las acciones que debe realizar.

Como se describió anteriormente, la primera acción de inicio es montar todos los sistemas de archivos. Esto está definido en la siguiente línea de /etc/inittab:

ARCHIVO /etc/inittabComando de inicialización

si::sysinit:/sbin/openrc sysinit

Esa línea dice a init que debe ejecutar /sbin/openrc sysinit al iniciar el sistema. El guión /sbin/openrc 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 guiones con enlaces simbólicos en /etc/runlevels/boot/. Esto se define en la siguiente línea:

ARCHIVO /etc/inittabInvocación de la orden de arranque

rc::bootwait:/sbin/openrc boot

Una vez más, el guión OpenRC lleva a cabo las tareas necesarias. Note que la opción dada a OpenRC (boot) corresponde al subdirectorio en /etc/runlevels/ que será usado.

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:

ARCHIVO /etc/inittabSelección del nivel de ejecución por defecto

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:

ARCHIVO /etc/inittabDefinición de los niveles de ejecución

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

La línea que define el nivel 3 vuelve a utilizar el guión openrc para iniciar los servicios (ahora con el argumento default). Observe también que el argumento de openrc coincide con el subdirectorio de /etc/runlevels/.

Al terminar OnpenRC, init decide qué consolas virtuales debe activar y qué órdenes se deben ejecutar para cada una:

ARCHIVO /etc/inittabDefinición de terminales

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

Niveles de ejecución existentes

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 guiones (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 son aquellos con un subdirectorio /etc/runlevels/: boot, default, nonetwork y single. El nivel de ejecución boot inicia todos los servicios necesarios para el sistema utilizados por los demás niveles de ejecución. Los tres niveles de ejecución restantes difieren en los servicios que inician: default se utiliza para las operaciones diarias, nonetwork se utiliza si no se requiere conectividad de red y single se utiliza cuando se necesita reparar el sistema.

Trabajando con los guiones de inicio

Los guiones iniciados por el proceso openrc son llamados guiones de inicio o init scripts. Cada guión en /etc/init.d/ puede ser ejecutado con los parámetros start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme o wantsme.

Para iniciar, parar o reiniciar un servicio (y todos los servicios dependientes), deben usarse start, stop y restart:

root #rc-service postfix start

Nota
Solo los servicios que necesiten del servicio nombrado serán parados o reiniciados. Los demás servicios dependientes, (aquellos que usen el servicio nombrado, pero que no lo necesiten) continuarán sin ser modificados.

Si desea parar un servicio, pero no los que dependan de el, puede usar la opción --nodeps junto con el parámetro stop:

root #rc-service --nodeps postfix stop

Para obtener el estado de un servicio (iniciado, detenido, ...), utilice el argumento status:

root #rc-service 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:

root #rc-service postfix zap

Para preguntar por las dependencias que tiene un servicio, puede usar iwant, iuse o ineed. Con ineed puede ver qué servicios son realmente necesarios para el correcto funcionamiento del servicio nombrado. Por otra parte, iwant o iuse muestran los servicios que pueden ser usados por el servicio nombrado, pero que no son requeridos para el correcto funcionamiento del servicio.

root #rc-service postfix ineed

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

root #rc-service postfix needsme

Modificar los niveles de ejecución

rc-update

El sistema de inicio 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 guiones de inicio.

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

Añadir y quitar servicios

En instrucciones anteriores ya hemos agregado guiones de inicio al nivel de ejecución default. Lo que quiere decir default se ha explicado antes en este documento. Junto al nivel de ejecucuión, el guión 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.

Además del nivel de ejecución, el guión rc-update requiere un segundo argumento que especifique la acción correspondiente: add, del o show. Por ejemplo:

root #rc-update del postfix default

La orden rc-update -v show mostrará todos los guiones de inicio y los niveles de ejecución donde ejecutará:

root #rc-update -v show

Es posible ejecutar también rc-update show (sin -v) simplemente para ver los guiones de inicio activos y sus respectivos niveles de ejecución.

Configurar los servicios

¿Por qué se necesita configuración adicional?

Los guiones de inicio pueden ser bastante complejos. Por lo tanto, no es recomendable que los usuarios los editen directamente, ya que esto los haría más propensos a errores. Sin embargo, es importante poder configurar servicios; por ejemplo, los usuarios podrían querer ejecutar el servicio con opciones adicionales.

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

El directorio conf.d

Gentoo provee una manera fácil de configurar estos servicios: cada guión de inicio configurable tiene un archivo dispuesto en /etc/conf.d/. Por ejemplo, el guión 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:

ARCHIVO /etc/conf.d/apache2Ejemplo de opciones para el guión de inicio apache2

APACHE2_OPTS="-D PHP5"

Este tipo de archivo de configuración contiene solamente variables (como en /etc/portage/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).

Crear guiones de inicio

Otro recurso útil es la guía de guiones de servicios de OpenRC.

¿Es necesario?

No, escribir un guión de inicio normalmente no hace falta, ya que Gentoo ofrece guiones 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 guión de inicio.

No utilice el guión de inicio proporcionado por el servicio si no está escrito explícitamente para Gentoo: los guiones de inicio de Gentoo no son compatibles con los guiones de inicio utilizados por otras distribuciones, a menos que la otra distribución utilice OpenRC.

Esquema

El esquema básico de un guión de inicio se muestra a continuación.

CÓDIGO Ejemplo de esquema de guión de inicio (tradicional)

#!/sbin/openrc-run

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

start() {
# (Órdenes requeridas para iniciar el servicio)
}

stop() {
# (Órdenes requeridas para parar el servicio)
}

CÓDIGO Esquema ejemplo de guión de inicio (actualizado)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="Demonio FooBar"
 
description="FooBar es un demonio que bebe"
extra_started_commands="drink"
description_drink="Abre su boca y traga reflexivamente"
 
depend() {
#  (Información de dependencias)
}
 
start_pre() {
#  (Comandos necesarios para prepararse para iniciar el servicio)
    # Asegurarse de que nuestros directorios son correctos
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commandos necesarios para limpiar después del servicio)
    # Limpiar todas las salpicaduras
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Empezando a beber"
    ${command} --drink beer
    eend $? "No he podido beberme ninguna cerveza :("
}

Cualquier guión de inicio requiere la definición de la función start() o de la variable command. El resto de secciones son opcionales.

Dependencias

Hay tres configuraciones relacionadas con las dependencias que pueden influir en el inicio o la secuenciación de los guiones de inicio: want, use y need. Además, existen dos métodos que influyen en el orden, llamados before y after. Estos dos últimos no son dependencias per se; no hacen que el guión de inicio falle si la dependencia especificada no está programada para iniciarse (o no se inicia).

• La configuración use informa al sistema de inicio que el guión utiliza la funcionalidad ofrecida por el guión indicado, pero no depende directamente de él. Algunos ejemplos son use logger y use dns: si los servicios están disponibles, se utilizarán, pero si el sistema no tiene un registrador o un servidor DNS, los servicios seguirán funcionando. Si los servicios existen, se inician antes que el guión que los utiliza.
• La configuración want es similar a use con una excepción: use solo tiene en cuenta los servicios que pertenezcan a un nivel de ejecución; want intentará iniciar cualquier servicio disponible, incluso si no se ha añadido a ningún nivel de ejecución.
• La configuración need indica una dependencia estricta: un guión que necesita otro guión no se iniciará antes de que este último se inicie correctamente. Además, si se reinicia el guión que necesita, también se reiniciará el guión que lo necesita.
• La configuración before garantiza que el guión se inicie antes que un guión específico, si este forma parte del nivel de ejecución. Por lo tanto, un guión de inicio xdm que define before alsasound se iniciará antes que el guión alsasound, pero solo si alsasound está programado para iniciarse en el mismo nivel de ejecución. Si alsasound no está programado para iniciarse en ese nivel de ejecución, la configuración before no tiene efecto y xdm se iniciará cuando el sistema de inicio lo considere más apropiado.
• De forma similar, after informa al sistema de inicio que el guión dado debe ejecutarse después de un guión específico si este forma parte del mismo nivel de ejecución. De lo contrario, la configuración no tiene efecto y el sistema de inicio ejecutará el guión cuando lo considere oportuno.

De lo anterior debería quedar claro que need es la única configuración de dependencia "verdadera", ya que afecta al inicio del guión. Todas las demás simplemente indican al sistema de inicio el orden en que los guiones pueden (o deben) iniciarse.

Dependencias virtuales

Muchos de los guiones de inicio de Gentoo dependen de cosas que no son propiamente guiones de inicio: dependencias virtuales.

Una dependencia virtual es una dependencia suministrada por un servicio, pero no únicamente por un servicio en concreto. Su guión 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.

Por ejemplo, considere la información de dependencia en el guión postfix:

ARCHIVO /etc/init.d/postfixInformación de dependencias del servicio poxfix

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

Como podemos ver, el servicio postfix:

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

Controlar la ordenación

Tal y como se ha descrito en la sección anterior, puede indicarle al sistema de inicio qué orden debe seguir para arrancar (o parar) los guiones. Este orden es manejado tanto por los ajustes de dependencia use y need, como por los ajustes de orden before y after. Como ya hemos descrito estos ajustes, echemos un vistazo al servicio portmap como ejemplo de guión de inicio.

ARCHIVO /etc/init.d/portmapInformación de dependencias del servicio portmap

depend() {
 need net
 before inetd
 before xinetd
}

Es posible utilizar el * para hacer referencia a todos los servicios en el mismo nivel de ejecución, aunque esto no es aconsejable.

CÓDIGO Usando el caracter englobador *

depend() {
 before *
}

Si el servicio debe escribir en discos locales, necesitará need localmount. Si coloca algo en /var/run/, como un archivo PID, entonces debe iniciarse después de after bootmisc:

CÓDIGO Declaración de dependencia que necesita localmount y ejecutarse después de bootmisc

depend() {
 need localmount
 after bootmisc
}

Funciones estándar

Además de la función depend(), también es necesario definir la función start(). Esta función contiene todos los comandos necesarios para inicializar el servicio. Se recomienda usar las funciones ebegin y eend para informar al usuario sobre lo que está sucediendo:

CÓDIGO Ejemplo de función start()

start() {
 if [ "${RC_CMD}" = "restart" ];
 then
  # Hacer algo en caso de que restart requiera algo más que parar y arrancar
 fi

 ebegin "Arrancando mi_servicio"
 start-stop-daemon --start --exec /path/to/mi_servicio \
  --pidfile /path/to/my_pidfile
 eend $?
}

Tanto --exec como --pidfile deben usarse en las funciones start() y stop(). Si el servicio no crea un archivo PID, use --make-pidfile si es posible, aunque se recomienda probarlo para asegurarse. De lo contrario, no use archivos PID. También es posible agregar --quiet a las opciones start-stop-daemon, pero no se recomienda a menos que el servicio sea muy verboso. Usar --quiet puede dificultar la depuración si el servicio no se inicia.

Tenga en cuenta también que el ejemplo anterior comprueba el contenido de la variable RC_CMD. OpenRC no admite una función de reinicio específica del guión; en su lugar, el guión debe comprobar el contenido de la variable RC_CMD para ver si se está llamando a una función (por ejemplo, start() o stop()) durante un reinicio.

Nota
Asegúrese que --exec efectivamente llame a un servicio y no solamente a un guión que lanza un servicio y termina -- después de todo, eso es lo que se espera que haga un guión de inicio.

Si requiere más ejemplos de funciones start(), favor leer directamente las fuentes de los guiones de inicio en su directorio /etc/init.d/.

Otra función que puede definir es stop(). Sin embargo, ¡No está obligado a definir esta función! Nuestro sistema de inicio es lo suficientemente inteligente para rellenar esta función por sí mismo si utiliza start-stop-daemon.

CÓDIGO Ejemplo de función stop()

stop() {
 ebegin "Parando mi_servicio"
 start-stop-daemon --stop --exec /path/to/mi_servicio \
  --pidfile /path/to/my_pidfile
 eend $?
}

Si el servicio ejecuta otro guión (por ejemplo, Bash, Python o Perl) y este guión cambia posteriormente de nombre (por ejemplo, de foo.py a foo), es necesario añadir la opción --name a start-stop-daemon. Esto debe especificar el nombre al que cambiará el guión. En este ejemplo, un servicio inicia foo.py, que cambia su nombre a foo:

CÓDIGO Ejemplo de definición de un servicio que lanza el guión foo

start() {
 ebegin "Arrancando mi_guion"
 start-stop-daemon --start --exec /path/to/mi_guion \
  --pidfile /path/to/my_pidfile --name foo
 eend $?
}

start-stop-daemon tiene una excelente página man si requiere más información:

user $man start-stop-daemon

La sintaxis de los guiones de inicio de Gentoo se basa en la shell POSIX ('sh'), por lo que se pueden usar construcciones compatibles con sh en los guiones de inicio. Evite otras construcciones, como las específicas de Bash, en los guiones de inicio para garantizar que sigan funcionando independientemente de los cambios que Gentoo pueda realizar en su sistema de inicio.

Añadir opciones personalizadas

Si el guión de inicio necesita admitir una opción distinta a las que ya hemos visto, añádala a una de las siguientes variables y cree una función con el mismo nombre. Por ejemplo, para admitir una opción llamada restartdelay:

• extra_commands - El comando está disponible con el servicio en cualquier estado
• extra_started_commands - El comando está disponible cuando se arranca el servicio
• extra_stopped_commands - El comando está disponible cuando se para el servicio

CÓDIGO Ejemplo de definición de la opción restartdelay

extra_started_commands="restartdelay"

restartdelay() {
 stop
 sleep 3 # Esperar 3 segundos antes de iniciarse de nuevo
 start
}

Importante
¡La función restart() no puede ser sobreescrita en OpenRC!

Variables para la configuración de servicios

No hay que hacer nada para dar soporte a un archivo de configuración en /etc/conf.d/: si su guión de inicio se ejecuta, los siguientes archivos serán automáticamente leídos -sourced- (es decir, las variables estarán disponibles para ser usadas):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

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

Cambiar el comportamiento del nivel de ejecución

¿Quién se podría beneficiar?

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 viaje (cuando no hay una red disponible). Con Gentoo puede modificar el comportamiento del nivel de ejecución para sus propios propósitos.

Por ejemplo, se puede crear un segundo nivel de ejecución "default", con otros guiones de inicio asignados. Al arrancar, el usuario puede seleccionar el nivel de ejecución "default" que se usará.

Utilizar 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:

root #mkdir /etc/runlevels/offline

Añada los guiones 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:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Incluso aunque se haya eliminado net.eth0 del nivel de ejecución offline, puede que udev quiera intentar iniciar cualquier dispositivo que detecte y lanzar los servicios apropiados, funcionalidad llamada hotplugging (enchufado en caliente). Por defecto Gentoo no habilita esta funcionalidad.

Si quiere habilitar el hotplugging pero solo para un conjunto seleccionado de guiones, utilice la variable rc_hotplug en /etc/rc.conf:

ARCHIVO /etc/rc.confHabilitando hotplugging en la interfaz WLAN

rc_hotplug="net.wlan !net.*"

Nota
Para más información sobre los servicios iniciados en función de dispositivos, consulte los comentarios del archivo /etc/rc.conf.

Ahora edite la configuración de su gestor de arranque y añada una nueva entrada para el nivel de ejecución offline. En dicha entrada, añada softlevel=offline como parámetero de arranque.

Utilizar 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 Variables de entorno →