Entendiendo el fichero /etc/inittab

Uno de los ficheros a los que casi ningún Unix sysadmin promedio le ha echado un vistazo, casi nunca cambia más sin embargo depende de él cada vez que reinicia el sistema, es el fichero /etc/inittab. Este modesto fichero controla lo que sucede cada vez que el sistema es reiniciado o forzado a cambiar de runlevel. Echemos un vistazo a las líneas de configuración de que le dicen a nuestro sistema qué está supuesto ha hacer cuando presionamos el botón de apagado.

El fichero /etc/inittab en sistemas Solaris y otros tipo Unix que comparten es tipo de arranque siguen las mismas reglas generales y muchas de las cuales son descritas más adelante son aplicacbles igualmente a dichas variantes Unix.

Para empezar, el fichero /etc/inittab usualmente inicia con un bloque de comentarios describiendo su contenido o dando crédito, como podemos ver debajo.

#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#
# Author: Miquel van Smoorenburg,# Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

Nuestro fichero /etc/inittab debe contener descripciones de los diferentes estados (runlevels) que el sistema puede asumir. Para aquellos que no están familiarizados con este concepto, un estado es básicamente una manera de describir qué se está ejecutando en el sistema cuando dicho estado es alcanzado. Por ejemplo, el estado 3 es "modo multiusuario completo" para la mayoría de los sistemas tipo Unix y tendrá usuarios logueandose y todos los servicios del sistema que se esperan para sustentar el uso del sistema.

He aquí un ejemplo de esta sección del fichero /etc/inittab. Notemos cómo este define cada estado para el sysadmin.

# Default runlevel. The runlevels used by RHS are:

# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode

# 2 - Multiuser, without NFS (The same as 3, if you do not have networking) 

# 3 - Full multiuser mode
# 4 - unused 

# 5 - X11 

# 6 - reboot (Do NOT set init default to this)
#

Una de las líneas más críticas en el fichero /etc/inittab es la que define el estado por defecto -- que es el  runlevel que será asumido cada vez que arrancamos el sistema sin especificar un estado de arranque alternativo. Para la mayoría de los sistemas tipo Unix, el runlevel por defecto es 3, como podemos ver debajo.

id:3:initdefault:


Desde que esta línea "initdefault" contiene "3" en el segundo campo, ejecutará el estado o runleve 3 por defecto.

Otra línea importante en los sistemas Linux in la de sysinit mostrada debajo. Esta le dice al sistema que ejecute el script /etc/rc.d/rc.sysinit cuando el sistema ha arrancado.

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

Una vez que el sistema ejecuta rc.sysinit y sabe el runlevel que se espera alcanzar durante el arranque, este seleccionará la línea apropiada de las listadas más abajo y ejecutará el script /etc/rc.d/rc con el argumento apropiado para el runlevel especificado. Normalmente esto será "rc 3", la cuarta línea de las siguientes below.

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1
l3:3:wait:/etc/rc.d/rc 3

l2:2:wait:/etc/rc.d/rc 2 

l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5 

l6:6:wait:/etc/rc.d/rc 6

Como ya ha debido suponer, el sistema escanea la segunda columna para la que corresponde al runlevel requerido por la configuración del initdefault o un comando init ejecutado por el usuario.

Entonces el script /etc/rc.d/rc usará el runlevel especificado para terminar cuál conjunto de scripts ejecutar. Bajo condiciones normales, rc se ejecutará con "3" como argumento y ejecutará todos los scripts ubicados dentro del directorio /etc/rc3.d. Esto ejecutará los scripts kill (los que comienzan con una "K") primero y después los scripts start (los que comienzan con "S") utilizando algo como esto:

for i in /etc/rc$runlevel.d/K* ; do

Si vemos el contenido del directorio /etc/rc3.d en un sistema Linux, verás algo como esto -- una larga colección de scripts kill y start que determinan qué se finaliza (si está en ejecución) y qué será iniciado.

$ ls /etc/rc2.d

K01dnsmasq         K36mysqld          K89netplugd         S15mdmonitor
K02avahi-daemon    K44rawdevices      K89pand             S25bluetooth
K02avahi-dnsconfd  K50netconsole      K89rdisc            S25pcscd
K02haldaemon       K50tux             K91capi             S26acpid
K02NetworkManager  K50vsftpd          K95firstboot        S26apmd
K03rhnsd           K69rpcsvcgssd      K95kudzu            S26hidd
K05atd             K72autofs          K99readahead_later  S50hplip
K05conman          K73ypbind          S00microcode_ctl    S55sshd
K05saslauthd       K74ipmi            S02lvm2-monitor     S56cups
K10dc_server       K74nscd            S04readahead_early  S56xinetd
K10psacct          K75netfs           S06cpuspeed         S80postfix
K10xfs             K85mdmpd           S08ip6tables        S85gpm
K12dc_client       K85messagebus      S08iptables         S90crond
K15httpd           K85rpcgssd         S08mcstrans         S95anacron
K20nfs             K85rpcidmapd       S09isdn             S95jexec
K24irda            K86nfslock         S10network          S97yum-updatesd
K25squid           K87multipathd      S11auditd           S99local
K30spamassassin    K87portmap         S12restorecond      S99smartd
K35dovecot         K88wpa_supplicant  S12syslog
K35winbind         K89dund            S13irqbalance

La siguiente línea no es familiar a los sysadmin de Solaris, pero la secuencia "control alt delete" será reconocida por todos los que han trabajado con sistemas Windows. Aquí tenemos esta secuencia particular señalizando la operación de apagado.

# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

La operación de apagado también es iniciada si una condificón de falla de energía es reconocida, como se muestra y se explica a continuación.

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"


# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


La siguiente seria de líneas utiliza la opción "respawn" para mantener los seris procesos mingetty ejecutándose en el sistema. Si alguien trata de finalizar uno de estos procesos como root, el proceso simplemente será regenerado (respawned). Solo los procesos críticos son configurados de esta manera para mantenerlos seguros de cualquier cosa que esté pasando en el sistema.


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6


Si sientes curiosidad por estos procesos, revísalos en el sistema y verás algo como esto:

$ ps -ef | grep getty
root      2818     1  0 Jan09 tty3     00:00:00 /sbin/mingetty tty3
root      2819     1  0 Jan09 tty4     00:00:00 /sbin/mingetty tty4
root      2821     1  0 Jan09 tty5     00:00:00 /sbin/mingetty tty5
root      2823     1  0 Jan09 tty6     00:00:00 /sbin/mingetty tty6
root      3092     1  0 Jan09 tty2     00:00:00 /sbin/mingetty tty2
root      3224     1  0 Jan09 tty1     00:00:00 /sbin/mingetty tty1
jdoe      4877  4684  0 20:33 pts/11   00:00:00 grep getty

Aquí tenemos otra línea "respawn" que verás en el fichero /etc/inittab. Esta es la línea que mantene el  xdm (X display manager) en marcha en el runlevel 5.

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

Desde esta línea y el comentario cerca de la parte superior del fichero, podemos ver que el runlevel 5 -- al menos en este sistema Linux en particular -- representa el multi-user mode con X11 ejecutándose.

La mayoría de los Linux sysadmins saben cómo agregar apropiadamente scripts kill y start al correspondiente directorio /etc/rc?.d para asegurarse de que los servicios son iniciados en el runlevel apropiado, pero quizás no sepan exactamente porqué agregar un script a /etc/rc3.d o /etc/rc2.d tiene el efecto que ellos quieren. Dedicar un poco de tiempo al fichero /etc/inittab podría responder cualquier pregunta que se tenga respecto de la forma en que traba este proceso.


Fuente: ITWorld