Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org/

Licencia de este documento: Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2024 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

Systemd es un nuevo sistema para la administración de dispositivos, eventos y servicios en GNU/Linux creado por Lennart Poettering. Es el reemplazo para sysvinit, upstart y udev en la mayoría de las distribuciones modernas. Se utiliza en CentOS 7, Red Hat™ Enterprise Linux 7 y versiones recientes de prácticamente todas las distribuciones de GNU/Linux, incluyendo Debian, Ubuntu™ y Fedora™.

A pesar de tratarse de tecnología de vanguardia, es compatible con los métodos utilizados en el pasado en SysV y LSB y las mejoras respecto de éstos incluyen capacidades de activación de zócalos y buses que permiten una mejor ejecución en paralelo de servicios independientes y el uso de cgroups para realizar el seguimiento de los procesos del servicio en lugar de utilizar PIDs. Ésto último impide que los servicios puedan evadir la administración de systemd.

Procedimientos.

Niveles de ejecución.

Los niveles de ejecución utilizados en SysV siguen siendo los mismos. Sin embargo en SystemD se administran como objetivos o targets. La siguiente tabla muestra los niveles de ejecución de SysV y su equivalente en SystemD:

Determinar el nivel de ejecución actual.

Si antes ejecutaba runlevel o who con la opción -r para determinar el nivel de ejecución actual. Éstos siguen funcionado exactamente igual, sin embargo se prefiere se utilice en su lugar lo siguiente:

systemctl list-units --type=target

La salida será similar a la siguiente:

UNIT                LOAD   ACTIVE SUB    DESCRIPTION
basic.target        loaded active active Basic System
cryptsetup.target   loaded active active Encrypted Volumes
getty.target        loaded active active Login Prompts
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target     loaded active active Local File Systems
multi-user.target   loaded active active Multi-User System
network.target      loaded active active Network
nss-lookup.target   loaded active active Host and Network Name Lookups
paths.target        loaded active active Paths
remote-fs.target    loaded active active Remote File Systems
slices.target       loaded active active Slices
sockets.target      loaded active active Sockets
swap.target         loaded active active Swap
sysinit.target      loaded active active System Initialization
timers.target       loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

15 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Lo anterior muestra que el sistema está en nivel de ejecución multi-user.target, es decir probablemente en nivel de ejecución 3. Recuerde de los niveles de ejecución 2, 3 y 4 apuntan indistintamente hacia multi-user.target.

Conmutar el nivel de ejecución.

Para conmutar al nivel de ejecución 3 en SysV antes se utilizaba lo siguiente:

init 3

Lo anterior sigue funcionando en SystemD, pero ahora se recomienda utilizar:

systemctl isolate multi-user.target

O bien:

systemctl isolate runlevel3.target

Para conmutar al nivel de ejecución 5 en SysV antes se utilizaba lo siguiente:

init 5

Lo anterior sigue funcionando en SystemD, pero ahora se recomienda utilizar:

systemctl isolate graphical.target

O bien:

systemctl isolate runlevel5.target

Cambiar el nivel de ejecución predeterminado del sistema.

Con SysV antes editaba el archivo /etc/inittab y establecía id:3:initdefault: para definir el nivel de ejecución 3. Con SystemD sólo se debe ejecutar lo siguiente:

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Con SysV antes editaba el archivo /etc/inittab y establecía id:5:initdefault: para definir el nivel de ejecución 5. Con SystemD sólo se debe ejecutar lo siguiente:

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Gestión de servicios con SystemD.

SysV utilizaba los directorios /etc/rc*.d debajo de los cuales se creaban enlaces simbólicos y determinaba qué servicios estaban habilitados en los distintos niveles de ejecución. SystemD utiliza en su lugar varios directorios debajo de /etc/systemd/system para los distintos niveles de ejecución. En el caso del nivel multiusuario, se puede examinar el contenido de /etc/systemd/system/multi-user.target.wants para determinar los servicios que están habilitados en éste.

Salvo por los servicios network y netconsole, todos los demás servicios antes utilizaban archivos dentro de /etc/init.d. Éstos han dejado de existir y han sido reemplazados por archivos para SystemD dentro de /usr/lib/systemd/system.

Listado, activación y desactivación de servicios.

En SysV antes se utilizaba lo siguiente para mostrar la lista de todos los servicios:

chkconfig --list

Con SystemD se ejecuta lo siguiente:

systemctl list-unit-files

En SysV antes se utilizaba lo siguiente para mostrar la lista de servicios activos en el nivel de ejecución 5:

chkconfig --list |grep "5:activo"

Con SystemD se ejecuta lo siguiente:

systemctl list-units

Instale un servicio para realizar las pruebas correspondientes:

dnf -y install nginx

En SysV antes se utilizaba lo siguiente para verificar en qué niveles de ejecución estaba activo un servicio —como nginx:

chkconfig --list algún-servicio-de-legado

Con SystemD se ejecuta lo siguiente:

systemctl is-enabled nginx

En SysV antes se utilizaba lo siguiente para habilitar un servicio:

chkconfig algún-servicio-de-legado on

Con SystemD se ejecuta lo siguiente:

systemctl enable nginx

En SysV antes se utilizaba lo siguiente para deshabilitar un servicio:

chkconfig algún-servicio-de-legado off

Lo anterior sigue funcionando por motivos de compatibilidad, pero se recomienda ejecutar en su lugar lo siguiente:

systemctl disable nginx

Detener, iniciar, reiniciar o consultar estado de servicios.

En SysV antes se utilizaba lo siguiente para iniciar un servicio:

service algún-servicio-de-legado start

El mandato service sigue funcionando por motivos de compatibilidad, pero se recomienda ejecutar en su lugar lo siguiente:

systemctl start nginx

Para habilitar e iniciar inmediatamente un servicio utilice systemctl con el parámetro enable, la opción `--now' y el nombre del servicio como argumento, como en el siguiente ejemplo:

systemctl enable --now nginx

Para deshabilitar e detener inmediatamente un servicio utilice systemctl con el parámetro enable, la opción --now y el nombre del servicio como argumento, como en el siguiente ejemplo:

systemctl disable --now nginx

Para deshabilitar por completo e impedir que servicio sea iniciado accidentalmente por otro proceso:

systemctl mask nginx

Para deshacer lo anterior:

systemctl unmask nginx

En SysV antes se utilizaba lo siguiente para reiniciar un servicio:

service algún-servicio-de-legado restart

El mandato service sigue funcionando por motivos de compatibilidad con algunos pocos programas de legado. Con SystemD se utiliza lo siguiente:

systemctl restart nginx

En SysV antes se utilizaba lo siguiente para detener un servicio:

service algún-servicio-de-legado stop

Con SystemD se utiliza lo siguiente:

systemctl stop nginx

En SysV antes se utilizaba lo siguiente para hacer que un servicio volviese a leer su configuración:

service algún-servicio-de-legado reload

Con SystemD se utiliza lo siguiente:

systemctl reload nginx

En SysV antes se utilizaba lo siguiente para consultar el estado de un servicio:

service algún-servicio-de-legado status

Con SystemD se utiliza lo siguiente:

systemctl status nginx