7.1. Introducción a los sistemas de inicio
Un sistema de inicio (init system) es el primer proceso que arranca el kernel y el responsable de lanzar todos los demás procesos del sistema. Es el ancestro de todos los procesos (PID 1). Durante décadas, el estándar fue SysVinit, inspirado en UNIX System V. Con el tiempo surgieron alternativas como Upstart (eventos) y, finalmente, systemd, que hoy domina casi todas las distribuciones Linux.
En el examen LFCS se espera que sepas gestionar servicios en cualquiera de estos tres entornos, aunque systemd es el más relevante actualmente. Debes ser capaz de:
- Identificar el sistema de inicio en uso.
- Iniciar, detener, habilitar y deshabilitar servicios.
- Cambiar de nivel de ejecución (SysVinit) o target (systemd).
- Diagnosticar el estado de un servicio.
Parte I: SysVinit
7.2. Fundamentos de SysVinit
SysVinit se basa en niveles de ejecución (runlevels) y scripts de inicio almacenados en /etc/init.d/. Cada runlevel define un conjunto de servicios que deben estar en ejecución. Los runlevels típicos son:
| Runlevel | Propósito |
|---|---|
| 0 | Apagado (halt) |
| 1 | Monousuario (modo rescate) |
| 2 | Multiusuario sin red (Debian/Ubuntu) |
| 3 | Multiusuario con red (modo texto) |
| 4 | No usado / personalizable |
| 5 | Multiusuario con interfaz gráfica (X11) |
| 6 | Reinicio |
En sistemas Debian/Ubuntu, los runlevels 2-5 son iguales por defecto. En RHEL/CentOS (anteriores a systemd), el 3 es multiusuario sin GUI y el 5 con GUI.
7.3. Scripts de inicio en /etc/init.d/
Cada servicio tiene un script de control en /etc/init.d/ que acepta argumentos como start, stop, restart, status, etc. Por ejemplo:
/etc/init.d/ssh status
/etc/init.d/networking restart
O usando el comando service (más portable):
service ssh status
service networking stop
El comando service ejecuta el script correspondiente con el entorno adecuado.
7.4. Enlaces simbólicos en /etc/rcX.d/
Para cada runlevel existe un directorio /etc/rcX.d/ (ej. /etc/rc3.d/) con enlaces simbólicos a los scripts de /etc/init.d/. Los nombres de los enlaces determinan la acción:
SXXnombre→ arranca el servicio (Start) al entrar al runlevel, donde XX es un número de prioridad (menor = antes).KXXnombre→ detiene el servicio (Kill) al salir del runlevel.
Ejemplo: S20ssh arranca SSH en ese runlevel; K80ssh lo pararía.
La gestión manual de estos enlaces se realiza con update-rc.d (Debian) o chkconfig (RHEL).
7.5. Herramientas de administración SysVinit
7.5.1. chkconfig (RHEL/CentOS hasta versiones 6)
Muestra y modifica los enlaces de los runlevels.
- Ver estado de un servicio:
chkconfig --list sshd - Habilitar servicio en runlevels 3 y 5:
chkconfig sshd on - Deshabilitar:
chkconfig sshd off - Añadir un servicio personalizado: primero se crea el script en
/etc/init.d/, luegochkconfig --add servicio
7.5.2. update-rc.d (Debian/Ubuntu)
- Añadir servicio con prioridades por defecto:
update-rc.d ssh defaults - Eliminar:
update-rc.d ssh remove - Especificar prioridades:
update-rc.d ssh start 20 2 3 4 5 . stop 80 0 1 6 .
Tras systemd, estas herramientas existen como compatibilidad, pero el verdadero control lo tiene systemd.
7.6. Cambiar de runlevel
Para cambiar en caliente:
init 3 # pasa a runlevel 3
telinit 6 # reinicia
Ver el runlevel actual: who -r o runlevel.
Parte II: Systemd
7.7. Systemd: el estándar moderno
Systemd es mucho más que un sistema de inicio: gestiona servicios, sockets, temporizadores, montajes, dispositivos y mucho más mediante unidades (units). Trabaja de forma paralela, lo que acelera el arranque. Las unidades se definen en archivos con extensión .service, .socket, .target, etc.
Para LFCS, el foco está en los servicios y en la herramienta principal: systemctl.
7.8. Tipos de unidades
*.service: un proceso o grupo de procesos (servicio clásico).*.socket: activa un servicio cuando se recibe tráfico en un socket.*.target: agrupa unidades, similar a un runlevel.*.mount,*.automount: puntos de montaje.*.timer: reemplaza a cron para tareas programadas.*.device: dispositivos reconocidos por udev.
7.9. Gestión de servicios con systemctl
7.9.1. Estado de un servicio
systemctl status sshd
Muestra si está activo, habilitado, PID, últimas líneas de log. Salida útil para diagnóstico.
7.9.2. Iniciar, detener, reiniciar
systemctl start sshd
systemctl stop sshd
systemctl restart sshd
systemctl reload sshd # recargar configuración sin detener (si el servicio lo soporta)
systemctl reload-or-restart sshd
7.9.3. Habilitar y deshabilitar en el arranque
systemctl enable sshd # crea enlace simbólico para arranque automático
systemctl disable sshd
systemctl is-enabled sshd # verifica si está habilitado
systemctl enable --now sshd # habilita y arranca a la vez
7.9.4. Enmascarar servicios
systemctl mask servicio # evita que se inicie manual o automáticamente (enlace a /dev/null)
systemctl unmask servicio
7.9.5. Listar unidades
systemctl list-units --type=service
systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service # muestra habilitación (enabled, disabled, static, masked)
7.10. Targets y runlevels
Systemd usa targets en lugar de runlevels. Los más importantes:
| Target | Equivalente runlevel | Descripción |
|---|---|---|
poweroff.target | 0 | Apagar sistema |
rescue.target | 1 | Modo rescate (monousuario) |
multi-user.target | 3 | Modo multiusuario sin GUI |
graphical.target | 5 | Modo multiusuario con GUI |
reboot.target | 6 | Reinicio |
Comandos útiles:
systemctl get-default # muestra el target por defecto
systemctl set-default multi-user.target # establecer el target por defecto
systemctl isolate graphical.target # cambiar en caliente (similar a init 5)
systemctl list-dependencies graphical.target # ver dependencias
7.11. El diario de systemd: journalctl
Systemd incluye un sistema de registro centralizado (journal). Se consulta con journalctl:
journalctl # todo el diario
journalctl -u sshd # solo mensajes del servicio sshd
journalctl -u sshd -f # seguir en tiempo real
journalctl --since "2024-01-01" --until "2024-01-02"
journalctl -p err # solo prioridad error o superior
journalctl --boot -1 # del arranque anterior
Para que los registros persistan tras reinicios, activa Storage=persistent en /etc/systemd/journald.conf y ejecuta systemctl restart systemd-journald.
7.12. Archivos de unidad personalizados
Aunque es un tema más avanzado, en LFCS puede aparecer la creación de un servicio simple.
Estructura de un archivo .service:
[Unit]
Description=Mi servicio personalizado
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mi-script.sh
Restart=on-failure
User=midemonio
[Install]
WantedBy=multi-user.target
Los archivos personalizados se colocan en /etc/systemd/system/. Luego:
systemctl daemon-reload # recargar configuraciones
systemctl enable mi-servicio
systemctl start mi-servicio
7.13. Herramientas complementarias
hostnamectl: gestiona el nombre del host.timedatectl: zona horaria y sincronización NTP.localectl: configuración regional.loginctl: sesiones de usuario.
Parte III: Upstart
7.14. Upstart: transición basada en eventos
Upstart fue desarrollado por Canonical para Ubuntu y utilizado hasta Ubuntu 14.04. Aunque hoy está obsoleto, puede aparecer en contextos de administración de sistemas heredados. Se basa en jobs definidos en /etc/init/.
Los comandos principales son:
initctl list: listar jobs y su estado.initctl start/stop/restart/status job.- Los scripts SysVinit también funcionan mediante compatibilidad (
service).
La sintaxis de un job de Upstart (en /etc/init/mi-job.conf):
description "Ejemplo"
start on runlevel [2345]
stop on runlevel [!2345]
exec /usr/bin/mi-programa
En el examen LFCS actual la probabilidad de preguntas específicas sobre Upstart es baja, pero no está de más conocer su existencia y comandos básicos.
7.15. Identificación del sistema de inicio
Para saber qué sistema se está usando:
ps -p 1 -o comm= # muestra el nombre del PID 1
ls -l /sbin/init # si es enlace a /lib/systemd/systemd, es systemd
O bien cat /proc/1/comm.
Si el sistema es systemd, systemctl es la herramienta; si es SysVinit, nos apoyamos en service y chkconfig/update-rc.d; si es Upstart, initctl y jobs.
7.16. Ejercicios prácticos
- Identifica tu sistema de inicio y anota el PID 1. Verifica qué gestor usa tu distribución.
- SysVinit (simulación en VM con Debian 7 o CentOS 6):
- Lista los scripts en
/etc/init.d/y los enlaces enrc3.d. - Usa
chkconfig --list(osysv-rc-conf) para ver servicios habilitados. - Deshabilita e inhabilita un servicio como
cron. - Cambia al runlevel 1 y vuelve al 3.
- Lista los scripts en
- Systemd:
- Lista todas las unidades de servicio en ejecución.
- Habilita y arranca
nginx(instálalo si no está). - Usa
journalctl -u nginxpara ver sus registros. - Cambia el target por defecto a
multi-user.target, reinicia y verifica que no carga GUI. Vuelve agraphical.target. - Crea un servicio simple que ejecute un script
echo "Hola"y registre en journal. Habilítalo y pruébalo.
- Upstart (si puedes emular Ubuntu 14.04):
- Crea un job básico y cárgalo con
initctl reload-configuration.
- Crea un job básico y cárgalo con
- Apagar y reiniciar usando el sistema de inicio correspondiente (comandos como
shutdown,reboot,systemctl poweroff).
7.17. Resumen y consejos para el examen LFCS
- Conoce a fondo
systemctl: start, stop, enable, disable, status, mask, list-units. - Comprende los targets y cómo cambiar entre ellos.
- Para SysVinit, domina
service,chkconfig/update-rc.dy la estructura de runlevels. - No menosprecies
journalctl; puede ser la salvación para diagnosticar fallos. - La gestión de servicios es transversal: en casi todos los capítulos usarás estos comandos (iniciar Apache, FTP, etc.). Así que interiorízalos.
- La creación de un pequeño servicio personalizado demuestra comprensión del sistema; practícala.
Dominar los sistemas de inicio te da control total sobre los procesos del sistema. En el próximo capítulo nos sumergiremos en la gestión de usuarios y grupos y el acceso sudo, otro pilar fundamental de la administración de sistemas.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
