Si algunos de nuestros foros, manuales, ALDOS, paquetería o proyectos te han resultado de ayuda, apreciaremos mucho nos apoyes con un donativo.

Introducción a SystemD.

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

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2016 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:

SysV SystemD Uso
0: runlevel0.target o poweroff.target Apaga el sistema
1 o S: runlevel1.target o rescue.target Nivel mono-usuario
2: runlevel2.target o multi-user.target Multi-usuario. Idéntico al nivel 3
3: runlevel3.target o multi-user.target Multi-usuario
4: runlevel4.target o multi-user.target Multi-usuario. Idéntico al nivel 3
5: runlevel5.target o graphical.target Multi-usuario con servidor de video
6: runlevel6.target o reboot.target Reinicia sistema
emergency emergency.target Intérprete de mandatos de emergencia.

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.

introduccion-systemd-01.png

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

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

chkconfig --list httpd

Con SystemD se ejecuta lo siguiente:

systemctl is-enabled httpd

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

chkconfig httpd on

Con SystemD se ejecuta lo siguiente:

systemctl enable httpd

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

chkconfig httpd off

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

 systemctl disable httpd

Detener, iniciar, reiniciar o consultar estado de servicios.

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

service httpd start

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

systemctl start httpd

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

service httpd restart

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

systemctl restart httpd

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

service httpd stop

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

systemctl stop httpd

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

service httpd reload

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

systemctl reload httpd

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

service httpd status

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

systemctl status httpd

Si algunos de nuestros foros, manuales, ALDOS, paquetería o proyectos te han resultado de ayuda, apreciaremos mucho nos apoyes con un donativo.

Última Edición: 30/08/2016, 15:06|Hits: 4,568 Ver la versión para imprimir