¿Cómo gestionar servicios del sistema con SysVinit, Systemd y Upstart?

Aprender Certificado Fundación Linux en España contenido Técnicos desde Cero en CiberED

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:

RunlevelPropósito
0Apagado (halt)
1Monousuario (modo rescate)
2Multiusuario sin red (Debian/Ubuntu)
3Multiusuario con red (modo texto)
4No usado / personalizable
5Multiusuario con interfaz gráfica (X11)
6Reinicio

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/, luego chkconfig --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:

TargetEquivalente runlevelDescripción
poweroff.target0Apagar sistema
rescue.target1Modo rescate (monousuario)
multi-user.target3Modo multiusuario sin GUI
graphical.target5Modo multiusuario con GUI
reboot.target6Reinicio

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

  1. Identifica tu sistema de inicio y anota el PID 1. Verifica qué gestor usa tu distribución.
  2. SysVinit (simulación en VM con Debian 7 o CentOS 6):
    • Lista los scripts en /etc/init.d/ y los enlaces en rc3.d.
    • Usa chkconfig --list (o sysv-rc-conf) para ver servicios habilitados.
    • Deshabilita e inhabilita un servicio como cron.
    • Cambia al runlevel 1 y vuelve al 3.
  3. Systemd:
    • Lista todas las unidades de servicio en ejecución.
    • Habilita y arranca nginx (instálalo si no está).
    • Usa journalctl -u nginx para ver sus registros.
    • Cambia el target por defecto a multi-user.target, reinicia y verifica que no carga GUI. Vuelve a graphical.target.
    • Crea un servicio simple que ejecute un script echo "Hola" y registre en journal. Habilítalo y pruébalo.
  4. Upstart (si puedes emular Ubuntu 14.04):
    • Crea un job básico y cárgalo con initctl reload-configuration.
  5. 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.d y 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.

Vistas: 1

Descubre más desde CIBERED

Suscríbete y recibe las últimas entradas en tu correo electrónico.

Scroll al inicio