Contenido


Aprenda Linux, 101

Niveles de ejecución, objetivos de arranque, apagar y reiniciar

Dé vida a su sistema

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Aprenda Linux, 101

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Aprenda Linux, 101

Manténgase en contacto por contenidos adicionales de esta serie.

Visión general

En este artículo, aprenda a apagar o a reiniciar su sistema Linux, avisar a los usuarios que el sistema se está cayendo, y cambiar al modo de usuario único o a un nivel de ejecución u objetivo de arranque más o menos restrictivo. Aprenda a:

  • Establecer el nivel de ejecución u objetivo de arranque predeterminado
  • Cambiar entre niveles de ejecución u objetivos de arranque
  • Cambiar a modo de usuario único
  • Apagar o reiniciar el sistema desde la línea de comando
  • Alertar a los usuarios acerca de los principales eventos del sistema, lo que incluye el cambio a otro nivel de ejecución u objetivo de arranque
  • Finalizar el proceso de forma adecuada

A menos que se especifique lo contrario, los ejemplos de este artículo utilizan un sistema Slackware 13.37 con el kernel 2.6.37. Los ejemplos upstart utilizan Ubuntu 14.04 LTS con un kernel 3.16.0. Los ejemplos systemd utilizan Fedora 22 con un kernel 4.0.4. Sus resultados pueden ser diferentes en otros sistemas.

Cómo ejecutar Linux

La mayor parte del tiempo los sistemas Linux se ejecutan como sistemas multiusuario, normalmente como un servidor en el que muchos procesos diferentes se ejecutan bajo varios IDs de usuario diferentes. A veces tienen una interfaz de usuario gráfica y atienden principalmente a un usuario único, mientras otras veces son un servidor sin cabeza que funciona para muchos usuarios. Cuando hay que hacer algun tipo de mantenimiento del sistema no se desea que todos esos usuarios intenten hacer las cosas, así que es necesario tener la capacidad de ejecutar el sistema por un único usuario en vez de muchos. También es necesario cambiar a este modo de una forma limpia, proporcionando los avisos adecuados a los usuarios que han iniciado sesión. También es necesario volver al funcionamiento normal lo más rápido posible. Este artículo muestra cómo hacerlo.

Este artículo ayuda a prepararse para el objetivo 101.3 del Tema 101 del examen 101 de Linux Server Professional (LPIC-1). El objetivo tiene un peso de 3.

Requisitos previos

Para sacar el máximo provecho de los artículos de esta serie hay que tener un conocimiento básico de Linux y un sistema Linux en funcionamiento para poder practicar los comandos que este artículo cubre. A veces, diferentes versiones de un programa formateará la salida de forma diferente, así que, es posible que sus resultados no tengan la misma apariencia que los listados e imágenes que se muestran aquí. En particular, los más recientes sistemas upstart y systemd están cambiando muchas cosas con las que los usuarios del tradicional proceso init de System V podrían estar familiarizados (vea Más allá de Init para obtener más detalles). Este artículo comienza discutiendo el tradicional proceso init de System V y de sus niveles de ejecución. Después, hablaremos sobre upstart y systemd, que son procesos de inicialización más recientes.

Niveles de ejecución de System V

El tradicional System V Los niveles de ejecución definen cuáles son las tareas que se pueden conseguir en el estado actual (o nivel de ejecución) de un sistema Linux. Los sistemas Linux tradicionales soportan tres niveles de ejecución básicos, y uno o más para el funcionamiento normal. Los niveles de ejecución básicos se muestran en Tabla 1.

Tabla 1. Niveles de ejecución básicos de Linux
NivelPropósito
0Apagar (o detener) el sistema
1Modo de usuario único; que normalmente tiene el alias s o S
6Reiniciar el sistema

Más allá de lo básico, la utilización de los niveles de ejecución difiere entre las distribuciones. Un conjunto de usos comunes se muestra en Tabla 2.

Tabla 2. Otros niveles de ejecución comunes de Linux
NivelPropósito
2Modo multiusuario sin red
3Modo multiusuario con red
5Modo multiusuario con red y el Sistema X Window

La distribución de Slackware utiliza el nivel de ejecución 4, en vez del 5, para los sistemas completos que ejecutan el sistema de X Window. Debian y sus derivados, como Ubuntu, utilizan un nivel de ejecución único para cualquier modo multiusuario, normalmente el nivel de ejecución 2. Asegúrese de consultar la documentación de su distribución.

Nivel de ejecución predeterminado System V

Cuando un sistema Linux se inicia, el nivel de ejecución predeterminado se determina desde id: de /etc/inittab. Listado 1 ilustra una parte del archivo /etc/inittab desde un sistema Slackware que se ha establecido para ejecutarse en modo multiusuario no gráfico.

Listado 1. Nivel de ejecución predeterminado en /etc/inittab
# Estos son los niveles de ejecución predeterminados en Slackware:
#   0 = detener
#   1 = modo de usuario único
#   2 = no utilizado (pero configurado igual que el nivel de ejecución 3)
#   3 = modo multiusuario (nivel de ejecución predeterminado de Slackware)
#   4 = X11 con KDM/GDM/XDM (gestores de sesiones)
#   5 = no utilizado (pero configurado igual que el nivel de ejecución 3)
#   6 = reiniciar

# Nivel de ejecución predeterminado. (No establecer en 0 ni en 6)
id:3:initdefault:

Edite este valor si quiere que su sistema inicie en un nivel de ejecución diferente, por ejemplo, el 4.

Cómo cambiar los niveles ejecución

Hay varias formas de cambiar los niveles de ejecución. Para hacer un cambio permanente, se puede editar /etc/inittab y cambiar el nivel predeterminado que acabamos de mostrar anteriormente.

Si sólo se necesita cargar el sistema desde un nivel de ejecución diferente para un arranque, se puede hacer esto. Por ejemplo, suponga que acaba de instalar un kernel nuevo, y que necesita construir algunos módulos de kernel después de que el sistema haya arrancado con el kernel nuevo, pero antes de que se inicie el Sistema X Window. Para lograr esto, podría iniciar el sistema en el nivel de ejecución 3. Esto se hace en el momento del arranque, editando la línea del kernel (GRUB o GRUB 2) o añadiendo un parámetro después del nombre del sistema seleccionado (LILO). Utilice un único dígito para especificar el nivel de ejecución deseado (3, en este caso). Ilustraremos el proceso con un ejemplo de GRUB. Suponga que su archivo /boot/grub/menu.lst contiene la estrofa que se muestra en Listado 2 para arrancar CentOS. Hemos roto la línea larga del kernel para la publicación con el caracter de barra invertida (\).

Listado 2. Estrofa típica de GRUB para arrancar CentOS 8
title CentOS (2.6.32-504.23.4.el6.x86_64)
	root (hd0,10)
	kernel /boot/vmlinuz-2.6.32-504.23.4.el6.x86_64 ro \
        root=UUID=2f60a3b4-ef6c-4d4c-9ef4-50d7f75124a2 rd_NO_LUKS \
        rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 \
        crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

Para encender este sistema en nivel de ejecución 3, espere hasta que se muestren las entradas del arranque, seleccione esta entrada e ingrese 'e' para editarla. Dependiendo de sus opciones de GRUB, es posible que tenga que pulsar una tecla para mostrar las entradas del arranque y, también, ingresar 'p' y una contraseña para desbloquear la edición. La pantalla de GRUB de nuestro sistema CentOS 6 tiene la siguiente apariencia Figura 1.

Figura 1. Cómo seleccionar una opción de arranque en GRUB
Seleccionar una opción de inicio en GRUB
Seleccionar una opción de inicio en GRUB

En este ejemplo, ahora deberían verse desplegadas las líneas del arranque, del kernel y de initrd. Mueva el cursor a la línea que empieza con "kernel" y pulse 'e' para editarla. La pantalla de GRUB de nuestro sistema CentOS 6 ahora tiene la siguiente apariencia Figura 2.

Figura 2. Cómo seleccionar la entrada del kernel para editar
Seleccionar la entrada del kernel para editar
Seleccionar la entrada del kernel para editar

Finalmente, mueva el cursor al final de la línea y añada un espacio y el dígito '3'. Si quiere puede eliminar 'quiet' o modificar cualquier otro parámetro según sus necesidades. La pantalla de GRUB de nuestro sistema CentOS 6 ahora tiene la siguiente apariencia Figura 3.

Figura 3. Cómo establecer el nivel de ejecución inicial a 3
Establecer el nivel de ejecución inicial en 3
Establecer el nivel de ejecución inicial en 3

Finalmente, pulse Intro para guardar los cambios, después, escriba 'b' para arrancar el sistema.

Notas:

  1. Los pasos para hacerlo con LILO o GRUB 2 difieren de los de GRUB, pero se mantiene el principio básico de editar cuando se inicia el kernel. Incluso las pantallas de GRUB en otros sistemas o distribuciones pueden tener una apariencia diferente a las que se muestran aquí. Normalmente habrá disponibles mensajes para ayudarle.
  2. En los sistemas que utilizan upstart o systemd, los niveles de ejecución son simulados y es posible que algunas cosas no funcionen exactamente podría esperarse. Esto es especialmente cierto si intenta cambiar un nivel de ejecución utilizando telinit

Cuando haya acabado su trabajo de configuración en el nivel de ejecución 3, es probable que quiera cambiar al nivel de ejecución 5. En un sistema init System V tradicional no es necesario reiniciar el sistema. Es posible utilizar el comando telinit para cambiar a otro nivel de ejecución. Utilice el comando runlevel para mostrar el nivel de ejecución anterior y el actual. Si el carácter resultante fuese una 'N', el nivel de ejecución no se habrá cambiado porque el sistema arrancó. Listado 3 ilustra cómo verificar y cambiar el nivel de ejecución.

Listado 3. Cómo verificar y cambiar el nivel de ejecución
[root@attic4-cent ~]# runlevel
N 3
[root@attic4-cent ~]# telinit 5

Después de ingresar telinit 5 verá que aparecen varios mensajes y su pantalla cambiará a la pantalla de inicio de sesión gráfico que está configurada. Abra una ventana de terminal y verifique que el nivel de ejecución haya sido cambiado como se muestra en Listado 4.

Listado 4. Cómo confirmar el nuevo nivel de ejecución
[ian@attic4-cent ~]$ runlevel
3 5

Si se utiliza el comando ls para mostrar un listado largo del comando telinit en un sistema que utiliza init en System V, como Slackware 37, verá que en realidad es un enlace simbólico hacia el comando init . Ilustramos esto en Listado 5. Si su sistema utiliza upstart o systemd, es posible que este no sea el caso.

root@attic4:~# # Slackware 37
root@attic4:~# ls -l $(qué telinit)
lrwxrwxrwx 1 root root 4 Aug 28  2011 /sbin/telinit -> init*

El ejecutable init sabe si fue llamado como init o telinit y se comporta conforme a eso. Dado que init se ejecuta como PID 1 en el momento del arranque, también es suficientemente inteligente para saber cuándo usted lo invoca utilizando init en vez de telinit. Si lo hace, asumirá que usted quiere que se comporte como si, en cambio, hubiese llamado telinit . Por ejemplo, usted podría utilizar init 5 en vez de telinit 5 para cambiar al nivel de ejecución 5.

Modos de usuario único

A diferencia de los sistemas operativos de las computadoras personales, como DOS o Windows, Linux es intrínsecamente un sistema multiusuario. Sin embargo, hay momentos en que eso puede ser un problema, como cuando es necesario recuperar una base de datos o un sistema de archivos principal, o instalar y probar algún hardware nuevo. Para estas situaciones, la respuesta es el nivel de ejecución 1, o modo de usuario único. La implementación depende de la distribución, pero normalmente habrá que iniciar en un shell con sólo un sistema mínimo. Normalmente, no se estará ejecutando ninguna red ni ningún (o muy pocos) demonios. En algunos sistemas hay que autenticarse iniciando sesión, pero en otros se va directamente a una línea de comando shell como usuario principal. Tenga mucho cuidado cuando se esté utilizando la autoridad principal, el modo de usuario único puede ser un salvavidas, pero, también puede destruir su sistema. Reinicie en modo multiusuario normal tan pronto como haya acabado.

Al igual que cuando cambia a niveles de ejecución multiusuario habituales, es posible cambiar al modo de usuario único con telinit 1. Como se observa en Tabla 1, 's' y 'S' son los alias para el nivel de ejecución 1, así que, por ejemplo, es posible utilizar telinit s.

Apagado limpio

Aunque es posible utilizar telinit o init para la actividad multiusuario y cambiar a modo de usuario único, esto puede ser bastante abrupto y provocar que los usuarios pierdan trabajo y procesos para terminar de forma anormal. El método preferido para apagar o reiniciar el sistema es utilizar el comando shutdown, que primero envía un mensaje de advertencia a todos los usuarios que han iniciado sesión y bloquea los siguientes inicios de sesión. Después, señala a init para cambiar los niveles de ejecución. Luego, el proceso init envía la señal SIGTERM a todos los procesos que se están ejecutando, dándoles la oportunidad de guardar los datos o, en caso contrario, finalizar adecuadamente. Después de 5 segundos, o de más tiempo si así está especificado, init envía una señal SIGKILL para forzar la finalziación de todos los procesos restantes.

De forma predeterminada, shutdown cambia al nivel de ejecución 1 (modo de usuario único). Es posible especificar la opción -h para parar el sistema, o la opción -r para reiniciarlo. Se mostrará un mensaje estándar además del mensaje que usted especifique. Es posible que se muestre el tiempo como un tiempo absoluto en formato hh:mm, o como un tiempo relativo, n, donde "n" es el número de minutos hasta que se apague. Para apagarlo de forma inmediata, utilice now, que es el equivalente a +0.

Si usted ha enviado un apagado retrasado y el tiempo todavía no ha transcurrido, puede cancelar el apagado pulsando Ctrl-c si el comando se está ejecutando en el primer plano, o enviando shutdown con la opción -c para cancelar un apagado pendiente. Listado 6 muestra varios ejemplos de cómo se utiliza shutdown, junto con las maneras de cancelar el comando.

Listado 6. Ejemplos de apagado
[root@attic4-cent ~]# apagado 5, es necesario el archivo de recuperación del sistema

Mensaje enviado desde ian@attic4-cent
	(/dev/pts/1) a las 18:11 ...

¡En 5 minutos se apagará el sistema para su mantenimiento!
Se necesita el archivo para recuperar el sistema
^Capagado: Apagado cancelado
[root@attic4-cent ~]# shutdown -r 10 Recargando el kernel actualizado&
[1] 5667
[root@attic4-cent ~]#
Mensaje trasmitido desde ian@attic4-cent
	(/dev/pts/1) a las 18:11 ...

¡En 10 minutos se va a apagar el sistema para reiniciarlo!
Recargando el kernel actualizado
fg
shutdown -r 10 Recargando el kernel actualizado
^Capagado: Apagado cancelado
[root@attic4-cent ~]# shutdown -h 23:59&
[1] 5669
[root@attic4-cent ~]#
Mensaje trasmitido desde ian@attic4-cent
	(/dev/pts/1) a las 18:11 ...

¡En 348 minutos se apagará el sistema para detenerlo!

[root@attic4-cent ~]# shutdown -c
apagado: Apagado cancelado
[1]+  Hecho                    shutdown -h 23:59

Observe en el único ejemplo que el último mensaje trasmitido salió a las 18:11, pero pedimos que se apagase a las 23:59, 6,5 horas después. La implementación del apagado de System V tradicional no envía ningún mensaje de advertencia si faltan más de 15 minutos para el apagado. En vez de eso, espera hasta que queden 15 minutos para el apagado programado y, después, envía el mensaje. Listado 7 muestra un ejemplo de System V en Slackware 37 y, también, muestra cómo se utiliza la opción -t para incrementar de 5 a 60 segundos el retraso predeterminado para las señales SIGTERM y SIGKILL.

Listado 7. Otro ejemplo de apagado
root@attic4:~# date;shutdown -t60 17 Es hora de hacer copias de seguridad&
Tue Jul 14 18:27:08 EDT 2015
[1] 2240
root@attic4:~#
Mensaje trasmitido desde el usuario principal (tty1) (Tue Jul 14 18:29:08 2015):

Es hora de hacer copias de seguridad
¡En 15 minutos se apagará el sistema para ponerlo en modo mantenimiento!
 

Cómo notificar a los usuarios con un wall

Si se cancela un apagado, se debe utilizar el comando wall para enviar una advertencia a todos los usuarios alertándoles del hecho de que el sistema no se está cayendo. El comando wall advierte desde la línea de comando o envía un mensaje desde un archivo. Una forma rápida de enviar un mensaje de varias líneas es utilizar echo -e y canalizar el resultado a wall. Ilustramos esto en Listado 8.

Listado 8. Cómo utilizar wall para advertir a los usuarios
[root@atticf22 ~]# wall El corte programado a las 23:59 ha sido cancelado
                                                                               
Mensaje trasmitido desde ian@atticf22 (pts/1) (Tue Jul 14 21:07:05 2015):

El corte programado a las 23:59 ha sido cancelado

[root@atticf22 ~]# echo -e "Estamos teniendo problemas con el sistemaCorte reprogramado a las 02:30" | wall
                                                                               
Mensaje trasmitido desde ian@atticf22 (pts/1) (Tue Jul 14 21:07:36 2015):

Estamos teniendo problemas en el sistema
Corte reprogramado a las 02:30

Como comentamos antes, también se puede utilizar telinit (o init) para apagar o reiniciar el sistema. Al igual que con otros usos de telinit, no se envía ninguna advertencia a los usuarios, y el comando entra en efecto inmediatamente, aunque seguirá habiendo un retraso entre las señales SIGTERM y SIGKILL. Para saber las opciones adicionales de telinit, inity shutdown, consulte las páginas apropiadas del manual.

Si no se quiere enfadar a los usuarios con cortes repentinos del sistema, es necesario notificárselos wall y con otros medios que se tengan a disposición.

Parar, reiniciar y apagar

Deberían conocerse algunos comandos más que están relacionados con apagar y reiniciar.

  • El comando haltpara el sistema.
  • El comando poweroff es un enlace simbólico al comando halt, que detiene el sistema y después intenta apagarlo.
  • El comando rebootes otro enlace simbólico al comando halt, que detiene el sistema y después lo reinicia.

Si se llama a alguno de ellos cuando el sistema no está en nivel de ejecución 0 o 6, en cambio, se invocará al comando shutdown.

Para obtener concesiones adicionales que se pueden utilizar por esos comandos, y para obtener información más detallada sobre su funcionamiento, consulte la página del manual.

System V /etc/inittab

Ahora, se puede estar preguntando porqué al pulsar Ctrl-Alt-Delete en algunos sistemas hace que se reinicien, o cómo se configura todo este nivel de ejecución. ¿Se acuerda del campo id de /etc/inittab que vimos anteriormente? Bueno, en /etc/inittab hay otros campos, y un conjunto de scripts de init scripts en directorios como rc1.d or rc5.d, donde su dígito identifica el nivel de ejecución que aplican los scripts de ese directorio. Listado 9 muestra el inittab completo de nuestro sistema Slackware 37.

Listado 9. inittab completo de Slackware 37
#
# inittab	Este archivo describe cómo el proceso INIT debería establecer
#		un determinado nivel de ejecución en el sistema.
#
# Versión:	@(#)inittab		2.04	17/05/93	MvS
#                                       2.10    02/10/95        PV
#                                       3.00    02/06/1999      PV
#                                       4.00    04/10/2002      PV
#                                      13.37    2011-03-25      PJV
#
# Autor:	Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modificado por:	Patrick J. Volkerding, <volkerdi@slackware.com>
#

# Estos son los niveles de ejecución predeterminados en Slackware:
#   0 = parar
#   1 = modo de usuario único
#   2 = no utilizado (pero configurado igual que el nivel de ejecución 3)
#   3 = modo multiusuario (nivel de ejecución predeterminado de Slackware)
#   4 = X11 con KDM/GDM/XDM (gestiones de sesiones)
#   5 = no utilizado (pero configurado igual que el nivel de ejecución 3)
#   6 = reiniciar

# Nivel de ejecución predeterminado. (No establecer en 0 o 6)
id:3:initdefault:

# Inicialización del sistema (se ejecuta cuando el sistema arranca).
si:S:sysinit:/etc/rc.d/rc.S

# Script a ejecutar cuando se pasa a usuario único (nivel de ejecución 1).
su:1S:wait:/etc/rc.d/rc.K

# Script a ejecutar cuando se pasa multiusuario.
rc:2345:wait:/etc/rc.d/rc.M

# Qué hacer en el "Saludo de Tres Dedos".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

# El nivel de ejecución 0 detiene el sistema.
l0:0:wait:/etc/rc.d/rc.0

# El nivel de ejecución 6 reinicia el sistema.
l6:6:wait:/etc/rc.d/rc.6

# Qué hacer cuando se corta la energía.
pf::powerfail:/sbin/genpowerfail start

# Si la energía vuelve, cancelar el apagado que se está ejecutando.
pg::powerokwait:/sbin/genpowerfail stop

# Estas son las entradas estándar de los getty del inicio de sesión en el modo multiusuario:
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

# Líneas de serie locales:
#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
#s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

# Líneas de conexiones telefónicas:
#d1:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS0 vt100
#d2:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS1 vt100

# El nivel de ejecución 4 también inicia /etc/rc.d/rc.4 para lanzar un gestor de pantalla para X.
# Los gestores de pantalla tienen preferencia en este orden:  gdm, kdm, xdm
x1:4:respawn:/etc/rc.d/rc.4

# Fin de /etc/inittab

Como de costumbre, las líneas que empiezan con # son comentarios. Otras líneas contienen varios campos con el siguiente formato:
id:runlevels:action:process

id
es un identificador único de entre uno y cuatro caracteres. Las versiones anteriores lo limitaban a dos caracteres, así que, es posible que se vea que sólo se utilizan dos caracteres.
runlevels
hace un listado con los niveles de ejecución para los que se debería realizar esta acción para este id. Si no aparece ningún nivel de ejecución, realiza la acción para todos los niveles de ejecución.
action
describe cuál de las diferentes acciones posibles se deberían realizar.
process
dice cuál es el proceso, si hubiera, que se debería ejecutar cuando se realiza la acción de esta línea.

Alguna de las acciones habituales que se pueden especificar en /etc/inittab se muestran en Tabla 3. Para conocer otras posibilidades, vea las páginas de inittab del manual.

Tabla 3. Algunas acciones habituales de inittab
AcciónPropósito
respawnReiniciar el proceso donde termine. Normalmente se utiliza para los procesos getty, que controlan los inicios de sesión.
waitInicia el proceso cuando el nivel de ejecución es introducido y espera a que termine antes de proceder con el init.
onceInicia el proceso cuando el nivel de ejecución es introducido.
initdefaultEspecífica el nivel de ejecución a introducir después de que el sistema arranque.
ctrlaltdelEjecuta los procesos asociados cuando init recibe la señal SIGINT, por ejemplo, cuando alguien que está en la consola del sistema pulsa CTRL-ALT-DEL.

Listado 10 muestra la entrada para Ctrl-Alt-Delete desde Listado 9. Ahora, usted puede ver por qué al pulsar Ctrl-Alt-Delete se reinicia el sistema.

Listado 10. Cómo capturar Ctrl-Alt-Delete
# Qué hacer en el "Saludo de Tres Dedos".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

Scripts de Inicialización de System V

Es posible que usted haya reparado que hay varias líneas en Listado 9, como:

# Script a ejecutar cuando se pasa multiusuario.
rc:2345:wait:/etc/rc.d/rc.M

En este ejemplo, init ejecutará el script (o comando) /etc/rc.d/M cuando se introduzcan los niveles de ejecución 2, 3, 4 o 5. init esperará hasta que se complete este comando antes de hacer algo más.

Esos scripts que init utiliza cuando inicia el sistema para cambiar los niveles de ejecución o apagarlo, normalmente se almacenan en el directorio /etc/init.d o en /etc/rc.d. Una serie de enlaces simbólicos de los directorios rcn.d, un directorio por cada nivel de ejecución n, normalmente controlan si un script se inicia cuando se ingresa un nivel de ejecución o se detiene al salir. Esos enlaces empiezan con una K o con una S, seguidas por un número de dos dígitos y, después, el nombre del servicio. Algunos ejemplos de un sistema más antiguo se muestran en Listado 11.

Listado 11. Scripts de Init
[root@pinguino ~]# find /etc -path "*rc[0-9]*.d/???au*"
/etc/rc.d/rc2.d/S27auditd
/etc/rc.d/rc2.d/K72autofs
/etc/rc.d/rc4.d/S27auditd
/etc/rc.d/rc4.d/S28autofs
/etc/rc.d/rc5.d/S27auditd
/etc/rc.d/rc5.d/S28autofs
/etc/rc.d/rc0.d/K72autofs
/etc/rc.d/rc0.d/K73auditd
/etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc6.d/K73auditd
/etc/rc.d/rc1.d/K72autofs
/etc/rc.d/rc1.d/K73auditd
/etc/rc.d/rc3.d/S27auditd
/etc/rc.d/rc3.d/S28autofs
[root@pinguino ~]# cd /etc/rc.d/rc5.d
[root@pinguino rc5.d]# ls -l ???a*
lrwxrwxrwx 1 root root 16 2008-04-07 11:29 S27auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 16 2008-04-01 07:51 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 15 2008-04-01 14:03 S44acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 13 2008-04-01 07:50 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 22 2008-04-01 07:54 S96avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 17 2008-11-17 13:40 S99anacron -> ../init.d/anacron

Aquí se ve que los servicios audit y autofs tienen Knn entradas en todos los niveles de ejecución y Snn entradas para los niveles de ejecución 3 y 5. La S indica que el servicio se inicia cuando se ingresa ese nivel de ejecución, mientras que en la entrada K indica que debería detenerse. El componente nn del nombre del enlace indica el orden de prioridad en el que se debería iniciar o para el servicio. En este ejemplo, audit se inicia antes de autofs, y se para después. Debido a que los enlaces K y S normalmente enlazan al mismo script, el script sabe si está entrando o dejando un nivel examinando el nombre del enlace desde el que fue llamado.

Sin embargo, Slackware utiliza un enfoque ligeramente diferente, como se muestra en Listado 12. Observe que todos los directorios /etc/rc[0-9].d están vacíos. El ingreso de un nivel de ejecución particular se controla por un script, como el script para ir a modo multiusuario, /etc/rc.d/rc.M que se utiliza cuando se ingresan los niveles de ejecución 2, 3, 4 o 5.

Listado 12. Scripts Init de Slackware 37
root@attic4:~# find /etc/rc[0-9].*
/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
/etc/rc6.d
root@attic4:~# ls /etc/rc.*/???a*
/etc/rc.d/rc.acpid*  /etc/rc.d/rc.atalk
/etc/rc.d/rc.alsa*   /etc/rc.d/rc.autofs

Compare el script /etc/rc.d/rc.autofs con los enlaces simbólicos /etc/rc.d/rc2.d/K72autofs y /etc/rc.d/rc4.d/S28autofs que apuntan a /etc/init.d/autofs en el ejemplo anterior.

Consulte las páginas del manual para init y inittab para obtener más información.

Más allá de Init

Como hemos visto aquí, el método tradicional para arrancar un sistema Linux se basa en el proceso init de UNIX System V. Implica la carga de un disco RAM inicial (initrd) y después pasar el control a un programa llamado init, programa que normalmente se instala como parte del paquete sysvinit. El programa init es el primer proceso del sistema y tiene el PID (ID de Proceso) 1. Ejecuta una serie de scripts en un orden predefinido para encender el sistema. Si no hay disponible algo que se espera, el proceso normalmente espera hasta que esté disponible. Aunque esto ha funcionado de forma adecuada para los sistemas en los que todo se conoce y se conecta cuando el sistema se inicia, los sistemas modernos que tienen dispositivos con enchufables en caliente, sistemas de archivos en red e, incluso, interfaces de red que es posible que no estén disponibles en el momento del inicio, presentan nuevos desafíos. No hay duda de que no es deseable esperar por hardware que no va a estar disponible durante mucho tiempo o, incluso, durante un tiempo relativamente largo.

En las siguientes secciones de este artículo describiremos dos alternativas a init de System V, upstart y systemd.

Si no se está seguro de cuál es la inicialización de su sistema, recuerde que el primer proceso que se inicia en su sistema tiene el ID de Proceso (PID) 1. Descubra cuál es el programa que se está ejecutando como PID1. Si se llama "init", descubra cuál es el paquete que lo proporciona. Listado 13 muestra cómo hacerlo en varios sistemas.

Listado 13. Cómo encontrar el paquete que proporciona init
[ian@atticf22 lpic-1]$ # Fedora 22
[ian@atticf22 lpic-1]$ ps -p 1 -o comm=
systemd
[ian@atticf22 lpic-1]$ # ¡Vaya! Es systemd

ian@attic4:~$ # Slackware 37
ian@attic4:~$ ps -p 1 -o comm=
init
ian@attic4:~$ grep  sbin/init /var/log/packages/*
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/init.new
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/initscript.sample
/var/log/packages/sysvinit-functions-8.53-x86_64-2:sbin/initlog
ian@attic4:~$ # init estilo System V

ian@attic-u14:~$ # Ubuntu 14
ian@attic-u14:~$ ps -p 1 -o comm=
init
ian@attic-u14:~$ dpkg -S `which init`
upstart: /sbin/init
ian@attic-u14:~$ # Upstart

ian@yoga-u15:~$ # Ubuntu 15.04
ian@yoga-u15:~$ ps -p 1 -o comm=
systemd
ian@yoga-u15:~$ # Ubuntu ha cambiado de upstart a systemd

[ian@attic4-cent ~]$ # CentOS 6
[ian@attic4-cent ~]$ ps -p 1 -o comm=
init
[ian@attic4-cent ~]$ rpm -q --whatprovides `which init`
upstart-0.6.5-13.el6_5.3.x86_64
[ian@attic4-cent ~]$ # Otro sistema upstart

En los sistemas upstart y systemd, quedarán vestigios de Init de System V, particularmente /etc/fstab y un /etc/inittab esquelético. El concepto de nivel de ejecución no se soporta directamente. Se soportan comandos de System V, como telinit , pero su función se correlaciona internamente con la activación y desactivación de trabajos de upstart o de unidades de systemd. No es preciso decir que la correlación a veces no es perfecta, así que, si se arranca en nivel de ejecución 3 y, después, utiliza telinit para cambiar al nivel de ejecución 5, es posible que su sistema no funcione exactamente como si lo hubiese reiniciado. La "Hoja introductoria de SysVinit a Systemd" (vea los Recursos) puede ayudarle a correlacionar los conceptos y los comandos de init de System V con systemd.

Upstart

En 2006 se presentó por primera vez en Ubuntu 6.10 ("Edgy Eft") un nuevo proceso de inicialización llamado upstart . Lo utilizan las versiones de 9 a 14 de Fedora y Red Hat Enterprise Linux (RHEL) 6, al igual que las distribuciones que se derivan de estas. Upstart ya ha suplantado al proceso init en Ubuntu, entre otros, aunque durante algún tiempo seguirán conservando vestigios de init y puede que no logren obtener todo la eficiencia de upstart.

Como contraste al conjunto estático de scripts de init que se utilizaban en los sistemas anteriores, el sistema upstart se basa en eventos. Los eventos se pueden desencadenar por cambios en el hardware, inicios, interrupciones o tareas, o por cualquier otro proceso que esté en el sistema. Los eventos se utilizan para desencadenar tareas o servicios, que se conocen colectivamente como trabajos. Así que, por ejemplo, la conexión de una unidad USB podría provocar que el servicio udev enviase un evento block-device-added , lo que, a su vez, podría provocar que una tarea definida verificase /etc/fstab y montase la unidad, si correspondiese. Otro ejemplo es que un servidor web Apache sólo se inicie cuando estén disponibles la red y los recursos necesarios de filesystem.

El programa de inicialización upstart reemplaza /sbin/init. Los trabajos de Upstart se definen en el directorio /etc/init y en sus subdirectorios. El sistema upstart actualmente procesará los scripts de /etc/inittab y de init de System V. En sistemas como las versiones recientes de Fedora, es probable que /etc/inittab sólo contenga la entrada del id para la acción initdefault. Los sistemas Ubuntu recientes no tienen /etc/inittab de forma predeterminada, aunque es posible crear uno si se quiere especificar un nivel de ejecución predeterminado.

Upstart también tiene el comando initctl para permitir la interacción con el demonio init de upstart. Esto permite iniciar o detener trabajos, hacer listas de trabajos, obtener el estado de los trabajos, emitir eventos, reiniciar el proceso init, etc. Listado 14 muestra cómo utilizar initctl para obtener una lista de trabajos de upstart en un sistema Fedora 13.

Listado 14. Cómo utilizar initctl para interactuar con el demonio de init de upstart
ian@attic-u14:~/data/lpic-1$ # Ubuntu 14
ian@attic-u14:~/data/lpic-1$ initctl list
gnome-keyring-gpg stop/waiting
indicator-application start/running, process 1935
unicast-local-avahi stop/waiting
update-notifier-crash stop/waiting
update-notifier-hp-firmware stop/waiting
xsession-init stop/waiting
dbus start/running, process 1734
update-notifier-cds stop/waiting
gnome-keyring-ssh stop/waiting
gnome-session (Unity) start/running, process 1802
ssh-agent stop/waiting
unity7 stop/waiting
unity-voice-service stop/waiting
upstart-dbus-session-bridge start/running, process 1837
indicator-messages start/running, process 1884
logrotate stop/waiting
indicator-bluetooth start/running, process 1885
unity-panel-service start/running, process 1835
hud start/running, process 1798
im-config start/running
unity-gtk-module stop/waiting
session-migration stop/waiting
upstart-dbus-system-bridge start/running, process 1789
at-spi2-registryd start/running, process 1801
indicator-power start/running, process 1889
update-notifier-release stop/waiting
indicator-datetime start/running, process 1891
unity-settings-daemon start/running, process 1794
indicator-sound start/running, process 1894
upstart-file-bridge start/running, process 1790
gnome-keyring stop/waiting
window-stack-bridge start/running, process 1754
indicator-printers start/running, process 1902
re-exec stop/waiting
upstart-event-bridge start/running, process 1745
unity-panel-service-lockscreen stop/waiting
indicator-session start/running, process 1918

Para saber más acerca de upstart, vea Temas relacionados.

Systemd

También está surgiendo una nueva inicialización del sistema llamada systemd . Systemd fue desarrollado por Lennart Poettering a principios de 2010. Describió las bases y el diseño en un post de un blog (vea Temas relacionados. Los primeros que la adoptaron fueron Fedora 15, openSUSE 12.1 y Mandriva 2011, entre otros. En la versión 15.04, Ubuntu ha cambiado de upstart a systemd.

Muchos procesos de demonios se comunican a través de sockets. Para obtener velocidad y mejorar el paralelismo en la inicialización del sistema, systemd crea esos sockets cuando arranca, pero sólo inicia las tareas asociadas cuando ese socket recibe una solicitud de conexión para los servicios. De esta forma, los servicios pueden iniciarse solo cuando son solicitados por primera vez, y no necesariamente en la inicialización del sistema. Los servicios que necesitan alguna otra facilidad se bloquearán hasta que esté disponible, así que, mientras ese proceso se inicia sólo se bloquearán aquellos servicios que están esperando otros procesos.

systemd amplia la idea de esperar por los servicios y utiliza autofs para definir puntos de montaje, así que el punto de montaje para un sistema de archivos está disponible, pero el montaje real se puede retrasar hasta que algún proceso intente abrir un archivo en el sistema de archivos o utilizarlo.

Estas ideas no sólo retrasan el inicio de los servicios hasta que se necesitan, también reducen la necesidad de la verificación de dependencias entre los servicios, ya que la interfaz del servicio puede estar preparada mucho antes de que el servicio tenga que estar disponible.

Como upstart, systemd puede procesar una inicialización existente desde /etc/inittab. También puede procesar /etc/fstab para controlar el montaje del sistema de archivos. La inicialización nativa de systemd gira en torno al concepto de unidades, que se pueden agrupar en grupos de control o cgroups. Entre los diferentes tipos de unidades, se pueden encontrar los siguientes:

  • Las unidades de servicio son demonios que se pueden iniciar, parar, reiniciar y recargar.
  • Las unidades socket encapsulan un socket en el sistema de archivos o en Internet.
  • Las unidades del dispositivo encápsulan un dispositivo en el árbol de dispositivos de Linux.
  • Las unidades de montaje encapsulan un punto de montaje en la jerarquía del sistema de archivos.
  • Las unidades de automontaje encapsulan un punto de automontaje en la jerarquía del sistema de archivos.
  • Las unidades objetivo agrupan otras unidades entre ellas, brindando una unidad de punto de control para otras múltiples unidades.
  • Las unidades instantáneas citan a otras unidades y se pueden utilizar para guardar y volver a instaurar el estado de todos los servicios y unidades del sistema init (por ejemplo, durante la suspensión).

Las unidades se configuran utilizando un archivo de configuración, lo que incluye el tipo de unidad como sufijo. Por ejemplo, cups.service, rpcbind.socket o getty.target. La ubicación de los archivos de configuración del sistema (por ejemplo, /etc/systemd/system) se puede determinar mediante el comando pkg-config , tal como se muestra en Listado 14, que muestra la ubicación en un sistema Fedora 17. Systemd también comprueba /usr/local/lib/systemd/system y /usr/lib/systemd/system para encontrar información de la configuración.

Listado 15. Cómo encontrar el directorio de configuración del sistema systemd
[ian@atticf22 ~]$ pkg-config systemd --variable=systemdsystemconfdir
/etc/systemd/system

El comando systemctl permite interrogar y controlar el demonio del sistema, lo que incluye iniciar y detener unidades, o detallar su estado. Listado 16 ilustra la utilización de systemctl para mostrar el estado de algunas de las unidades systemd que están en mi sistema Fedora 22.

Listado 16. Salida parcial de systemctl
[ian@atticf22 ~]$ systemctl --no-pager
  UNIDAD                        CARGA  ACTIVA SUB       DESCRIPCIÓN
  proc-sys-fs-binfmt_misc.automount cargado activo en ejecución   Forma Arbitraria de Archivo Ejecutable
  sys-devices-pci0000:00-0000:00:02.0-0000:01:00.1-sound-card1.device cargado activo enchufado
Controlador de Audio HDMI GF119
  sys-devices-pci0000:00-0000:00:06.0-0000:03:00.0-net-enp3s0.device cargado activo enchufado
RTL8111/8168/8411 PCI Express
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device
cargado activo enchufado   WDC_WD6401AALS-00L3B2 /grubfil
...
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda9.device
cargado activo enchufado WDC_WD6401AALS-00L3B2 9
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda.device
cargado activo enchufado   WDC_WD6401AALS-00L3B2
...
  sys-devices-pci0000:00-0000:00:12.2-usb1-1\x2d6-1\x2d6:1.2-sound-card2.device cargado activo enchufado
   Webcam C310
  sys-devices-pci0000:00-0000:00:14.1-ata6-host5-target5:0:0-5:0:0:0-block-sr0.device cargado activo enchufado
   Optiarc_DVD_RW_AD-7240S
...
  sys-module-configfs.device    cargado activo enchufado   /sys/module/configfs
  sys-module-fuse.device        cargado activo enchufado   /sys/module/fuse
...
  sys-subsystem-net-devices-enp3s0.device cargado activo enchufado   RTL8111/8168/8411 PCI Express
  sys-subsystem-net-devices-virbr0.device cargado activo enchufado   /sys/subsystem/net/devices/vir
  sys-subsystem-net-devices-virbr0\x2dnic.device cargado activo enchufado   /sys/subsystem/net/devices/vir
  -.mount                       cargado activo montado   /
...
  cups.path                     cargado activo en espera   Programador de CUPS
  systemd-ask-password-plymouth.path cargado activo en espera   Reenviar Solicitudes de Contraseñas a P
  systemd-ask-password-wall.path cargado activo en espera   Reenviar Solicitudes de Contraseñas a W
  session-1.scope               cargado activo abandonado Sesión 1 del usuario ian
  session-2.scope               cargado activo en ejecución   Sesión 2 del usuario ian
  session-c1.scope              cargado activo en ejecución   Sesión c1 del usuario gdm
...
  crond.service                 cargado activo en ejecución   Programador de Comandos
  cups.service                  cargado activo en ejecución   Programador de CUPS
  dbus.service                  cargado activo en ejecución   Bus de Mensajes de Sistema D-Bus
  dracut-shutdown.service       cargado activo salido    Restaurar/ejecutar/initramfs al apagar
  fedora-import-state.service   cargado activo salido    Importar configuración de la red f
  fedora-readonly.service       cargado activo salido    Configurar soporte raíz modo solo lectura
...
● mcelog.service                cargado fallo fallo    Verificación de Máquina de Inicio de Sesión de Excepción
  NetworkManager.service        cargado activo en ejecución   Gestor de Red
  nfs-config.service            cargado activo salido    Configuración NFS previa al proceso
  packagekit.service            cargado activo en ejecución   Demonio PackageKit
...
  cups.socket                   cargado activo en ejecución   Programador de CUPS
  dbus.socket                   cargado activo en ejecución   Socket de Bus de Mensajería de Sistema D-Bus
  dm-event.socket               cargado activo en escucha FIF de demonio de eventos del mapeador de dispositivos
...
  sockets.target                cargado activo activo    Sockets
  sound.target                  cargado activo activo    Tarjeta de sonido
  swap.target                   cargado activo activo    Swap
  sysinit.target                cargado activo activo    Inicialización de Sistema
  timers.target                 cargado activo activo    Cronómetros
  dnf-makecache.timer           cargado activo en espera   cronómetro makecache dnf
  systemd-tmpfiles-clean.timer  cargado activo en espera   Limpieza diaria de Dir Temporal

CARGA   = Refleja si la definición de la unidad se cargó de forma adecuada.
ACTIVO = El estado de activación de la unidad de alto nivel, es decir, la generalización de SUB.
SUB    = El estado de activación de la unidad de bajo nivel, los valores dependen del tipo de unidad.

Lista de 164 unidades cargadas. Pasar todo para también ver las unidades cargadas pero inactivas.
Para mostrar todos los archivos de las unidades instaladas utilice 'systemctl list-unit-files'.

La última parte del nombre de la unidad (como el dispositivo, la ruta y el objetivo) es el tipo de unidad.

El comando systemctl permite interrogar y controlar las unidades del sistema. Mostramos algunos ejemplos en Listado 17 donde primero interrogamos al demonio del servidor SSH (sshd.service). Después, lo detenemoss y volvemos a verificar su estado. Finalmente, lo volvemos a iniciar.

Listado 17. Algunas acciones de systemctl
[root@atticf22 ~]# # Fedora 22
[[root@atticf22 ~]# estado systemctl sshd.service
● sshd.service - Demonio del servidor OpenSSH
   Cargado: cargado (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Activo: activo (en ejecución) desde el miércoles 15-07-2015 10:24:03 EDT; hace 5 h y 42 m
     Documentos: man:sshd(8)
           man:sshd_config(5)
 Main PID: 765 (sshd)
   CGroup: /system.slice/sshd.service
           └─765 /usr/sbin/sshd -D

Jul 15 10:24:03 atticf20 systemd[1]: Iniciado el demonio del servidor OpenSSH.
Jul 15 10:24:03 atticf20 systemd[1]:  Iniciando el demonio del servidor OpenSSH...
Jul 15 10:24:03 atticf20 sshd[765]: Escucha del servidor 0.0.0.0 puerto 22.
Jul 15 10:24:03 atticf20 sshd[765]: Escucha del servidor :: puerto 22.
[root@atticf22 ~]# parar systemctl sshd.service
[root@atticf22 ~]# estado de systemctl sshd.service
● sshd.service - demonio del servidor OpenSSH
   Cargado: cargado (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Activo: inactivo (parado) desde el miércoles 15-07-2015 16:06:28 EDT; hace 3 s
     Documentos: man:sshd(8)
           man:sshd_config(5)
  Proceso: 765 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
 PID Principal: 765 (code=exited, status=0/SUCCESS)

Jul 15 10:24:03 atticf20 systemd[1]: Iniciado el demonio del servidor OpenSSH.
Jul 15 10:24:03 atticf20 systemd[1]:  Iniciando el demonio del servidor OpenSSH...
Jul 15 10:24:03 atticf20 sshd[765]: Servidor escuchando en 0.0.0.0 puerto 22.
Jul 15 10:24:03 atticf20 sshd[765]: Servidor escuchando en :: puerto 22.
Jul 15 16:06:28 atticf22 systemd[1]: Interrumpiendo el demonio del servidor OpenSSH...
Jul 15 16:06:28 atticf22 systemd[1]: Interrumpiendo el demonio del servidor OpenSSH.
[root@atticf22 ~]# iniciar systemctl sshd.service

Para saber más acerca de systemd, vea Temas relacionados.

Esto finaliza su introducción a los niveles de ejecución, apagar y reiniciar Linux.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=1062685
ArticleTitle=Aprenda Linux, 101: Niveles de ejecución, objetivos de arranque, apagar y reiniciar
publish-date=12212015