Systemd sistema administrador de servicios para Linux: 2a parte.

Systemd es un sistema y administrador de servicios para Linux, compatible con scripts de inicio (init) SysV y LSB. systemd proporciona capacidades de paralelización agresivas, utiliza socket y activación D-Bus para iniciar los servicios, ofrece la puesta en marcha de demonios bajo demanda, realiza el seguimiento de procesos utilizando Linux cgroups, soporta copia instantánea de volumen y la restauración de estado del sistema, mantiene puntos de montaje y automontaje e implementa un elaborado servicio lógico de control transaccional basado en la dependencia.

 

Systemadm.

Hay una interfaz de usuario mínima, systemadm que permite iniciar/detener/examinar servicios. Es parte del paquete systemd-gtk. Es un trabajo en progreso y aún no es funcional, pero útil como herramienta de depuración. Está escrito en Vala. No lo utilice por ahora a menos que sea un desarrollador (... y más avanzados).

 

Compatibilidad scripts de inicio (init) SysV: toma ventajas de LSB y encabezados Red Hat de chkconfig si están disponibles, si no, utiliza otra forma de información disponible, como las prioridades de inicio en /etc/rc.d. Estos scripts init simplemente son considerados una fuente diferente de configuración, facilitando la ruta de actualización a los servicios de systemd adecuados.

 

• Archivo de configuración /etc/fstab: es otra fuente de configuración. Usando la opción comment= de fstab es posible marcar entradas en /etc/fstab para que sean controladas por systemd a través de los puntos de automontaje.

• Soporta un mecanismo simple de plantillas/instancia: por ejemplo, en lugar de tener seis archivos de configuración para seis gettys, tiene sólo un archivo getty@.service que crea una instancia getty@tty2.service y cosas por el estilo. La parte de la interfaz incluso puede ser heredada por las expresiones de la dependencia, es decir, es fácil de codificar que un servicio dhcpcd@eth0.service cargue avahi-autoipd@eth0.service, mientras permita la eth0 con cadena de comodines.

• Compatibilidad, hasta cierto punto, con /dev/initctl. De hecho, esta compatibilidad se implementa con un servicio FIFO-activated, que simplemente traduce estas solicitudes heredadas a las peticiones D-Bus. Efectivamente esto significa el antiguo shutdown, poweroff y comandos similares de Upstart y sysvinit siguen trabajando con systemd.

• Compatibilidad con utmp y wtmp (En una medida que es mucho más que saludable, dada la mala calidad que hoy tienen utmp y wtmp).

Para todos los detalles ver Una pequeña lista de otras características en el blog del desarrollador.

 

Herramientas.

 

• systemctl: usada para examinar y controlar el estado del sistema systemd y el administrador de servicios.
• systemd-cgls: muestra recursivamente el contenido del árbol de jerarquías de un determinado grupo de control de Linux.
• systemadm: una interfaz gráfica para el sistema systemd y el administrador de servicios que permite la introspección y el control de systemd. Es parte del paquete systemd-gtk. Esta es una versión temprana y necesita más trabajo. No la utilice por ahora a menos que sea un desarrollador.

Ver las páginas man para obtener más detalles.

Línea de comandos de arranque del Kernel.

 

En el arranque systemd activa (por defecto), la unidad target default.target cuyo trabajo es activar servicios y otras unidades arrastrándolas a través de las dependencias.

 

Para reemplazar la unidad a activar, systemd analiza sus propios argumentos de la línea de comandos del kernel a través de la opción de línea de comandos systemd.unit=. Esto puede utilizarse para arrancar temporalmente una unidad de arranque distinto. Los niveles de ejecución clásicos se reemplazan como sigue:

systemd.unit=rescue.target es una unidad target especial para configurar el sistema base y un shell de rescate (similar al nivel 1 de ejecución); systemd.unit=emergency.target, es muy similar a passing init=/bin/sh pero con la opción para arrancar el sistema completo desde allí; systemd.unit=multi-user.target para configurar un sistema multiusuario no gráfico; systemd.unit=graphical.target para configurar una pantalla gráfica de inicio de sesión.

 

Para obtener más información acerca de estas unidades de arranque systemd especial, ver la página man systemd.special.

 

¿Cuál es el estado de systemd en Fedora?

Fedora 14 lo presentó como un avance de esta tecnología. Es el predeterminado en Fedora 15 y superior, en sustitución de Upstart.

 

¿Todos los init heredados de System V deben convertirse en archivos service de systemd o equivalentes?

 

Muchos de los servicios principales (/lib/systemd/system tienen y pueden comprobar el estado en http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) si han sido convertidos pero no todos ellos todavía. La transición está prevista para Fedoral 16. Detalles en http://fedoraproject.org/wiki/Features/SysVtoSystemd. systemd es totalmente compatible con los scripts de inicio (init) heredados.

 

¿Qué es la herramienta para administrar los servicios con systemd?

systemctl es la herramienta principal para usar. Combina la funcionalidad de ambos servicios y chkconfig en una única herramienta que puede utilizar por ejemplo para activar/desactivar servicios permanentemente o sólo para la sesión actual.

lista de todos los servicios en ejecución, etc.:

systemctl

Consulte man systemctl para más detalles. systemd-cgls enumera los procesos en ejecución en forma de árbol. Puede mostrar de forma recursiva el contenido de cualquier grupo de control determinado. Consulte man systemd-cgls para más detalles.

 

¿Cómo iniciar/detener o activar/desactivar servicios?

Activa un servicio inmediatamente:

systemctl start foo.service

Desactiva un servicio inmediatamente:

systemctl stop foo.service

Reinicia un servicio:

systemctl restart foo.service

Muestra el estado de un servicio, incluyendo si se está ejecutando o no:

systemctl status foo.service

Permite un servicio para iniciarse en el arranque:

systemctl enable foo.service

Deshabilita un servicio para que no se inicie durante el arranque:

systemctl disable foo.service

Comprueba si un servicio ya está habilitado o no:

systemctl is-enabled foo.service; echo $?

0 indica que está activado, y 1 indica que está desactivado. En Fedora 17, además del código de retorno, «activado» o «desactivado» se imprimirá en la salida estándar (stdout).

 

Consulte man systemctl para más detalles.

 

¿Cómo se puede cambiar el nivel de ejecución (runlevel)?

systemd tiene el concepto de targets, que es un reemplazo más flexible para los niveles de ejecución en sysvinit.

 

El nivel de ejecución 3 es emulado por multi-user.target. El nivel de ejecución 5 es emulado por graphical.target. runlevel3.target es un enlace simbólico a multi-user.target y runlevel5.target es un enlace simbólico a graphical.target.

Puede cambiar a 'nivel de ejecución 3' ejecutando

systemctl isolate multi-user.target (o) systemctl isolate runlevel3.target

Puede cambiar a 'nivel de ejecución 5' ejecutando

systemctl isolate graphical.target (o) systemctl isolate runlevel5.target

 

¿Cómo se puede cambiar el nivel de ejecución predeterminado?

systemd utiliza symlinks (enlaces simbólicos) para señalar el nivel de ejecución predeterminado. Tiene que eliminar primero el symlink existente antes de crear uno nuevo.

rm /etc/systemd/system/default.target

Cambiar a nivel de ejecución 3 por defecto

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

Cambiar a nivel de ejecución 5 por defecto

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

systemd no utiliza el archivo /etc/inittab.

¿Cómo saber el nivel de ejecución actual?

El comando runlevel todavía funciona con systemd. Puede continuar usándolo, sin embargo los runlevels son un concepto heredado en systemd y es emulado a través de 'targets' y múltiples targets que se pueden activar al mismo tiempo. Por lo que es el equivalente en términos de systemd.

systemctl list-units --type=target

¿Cómo apagar la máquina?

Se puede utilizar

poweroff

Algunas posibilidades más son: halt -p, init 0, shutdown -P now

Tenga en cuenta que halt solía trabajar igual a poweroff en anteriores versiones de Fedora, pero systemd distingue entre los dos, por lo que halt sin parámetros ahora hace exactamente lo que dice - simplemente se detiene el sistema sin apagarlo.

¿Funciona el comando service con systemd?

Sí. Se ha modificado para llamar a systemctl automáticamente cuando trate con archivos service de systemd. Así que cualquiera de los siguientes comandos hace lo mismo.

service NetworkManager stop

(o)

systemctl stop NetworkManager.service

 

¿Funciona el comando chkconfig con systemd?

Sí, para encender/apagar servicios, la compatibilidad ha proporcionado ambas formas. chkconfig ha sido modificado para llamar a systemctl al tratar con archivos service de systemd. También systemctl llama automáticamente a chkconfig cuando se trata de un archivo init sysv tradicional.

 

Así que cualquiera de los siguientes comandos hace lo mismo

chkconfig NetworkManager off

(o)

systemctl disable NetworkManager.service

chkconfig --list no lista servicios de systemd, sólo servicios de Sys V. La salida de chkconfig toma nota de esto, junto con la información adicional presentada.

 

¿Funciona system-config-services con systemd?

Fedora 15 o la versión superior de system-config-services puede hacer frente a los archivos service de systemd. Si tiene problemas, presente un informe de fallos.

 

¿Cómo se puede cambiar el número de gettys funcionando por defecto?

Para agregar otro getty:

Simplemente coloque otro symlink (enlace simbólico) para instanciar a otro getty en el directorio getty.target.wants/ :

ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
systemctl daemon-reload
systemctl start getty@tty9.service

Para quitar un getty:

Simplemente quite los symlinks (enlaces simbólicos) del getty que quiere deshacerse en el directorio getty.target.wants/ :

rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
systemctl daemon-reload
systemctl stop getty@tty5.service getty@tty6.service

systemd no utiliza el archivo /etc/inittab.

¿Cómo configuro el inicio de sesión automático en una terminal de consola virtual?

Primero crear un nuevo servicio similar a getty@.service:

# cp /lib/systemd/system/getty@.service \
     /etc/systemd/system/autologin@.service
# ln -s /etc/systemd/system/autologin@.service \
        /etc/systemd/system/getty.target.wants/getty@tty8.service

a continuación editar ExecStart, Restart y los valores de Alias, como este:

...

ExecStart=-/sbin/mingetty --autologin USERNAME %I
Restart=no
...
Alias=getty.target.wants/getty@tty8.service

y finalmente volver a cargar el demonio e iniciar el servicio:

systemctl daemon-reload
systemctl start getty@tty8.service

Tenga en cuenta que si sale de la sesión tty8, puede usarla hasta el siguiente reinicio o arranque manual por systemctl, excepto si deja Restart como 'always', pero recomiendo evitar esto por razones de seguridad.

 

¿Cómo personalizar un archivo unidad o agregar uno personalizado?

Los archivos unidad de /etc/systemd/system tienen una mayor precedencia sobre archivos unidad de /lib/systemd/system. Copiarlos desde éste último al anterior y personalizarlos según sus requisitos.

 

Si una línea comienza con .include seguida de un nombre de archivo, el archivo especificado se analizará en este punto. Asegúrese que el archivo que se incluye tiene los encabezados de sección adecuados antes de cualquier directiva.

Se debe usar la instrucción .include en lugar de copiar el conjunto de archivos unidad de /lib/systemd/system a /etc/systemd/system si es posible. Esto le permitirá actualizar correctamente las directivas sin cambios durante las actualizaciones futuras del paquete.

 

Tenga cuidado cuando use .include junto con directivas que puedan definirse varias veces (como EnvironmentFile=), ya que sólo podemos añadir nuevas directivas, pero no podemos quitar las ya definidas. Tenemos que copiar todos los archivos de /lib/systemd/system a /etc/systemd/system en este caso.

Digamos que usamos un servidor lighttpd y queremos bajar su valor de niceness. Todo lo que tenemos que hacer es añadir Nice=-5 en el archivo lighttpd.service. Podemos hacer esto copiando todo el archivo de /lib/systemd/system/lighttpd.service a /etc/systemd/system/lighttpd.service o creando el siguiente archivo en /etc/systemd/system/lighttpd.service:

.include /lib/systemd/system/lighttpd.service
[Service]
Nice=-5

No olvide recargar el demonio de systemd usando systemctl daemon-reload después de editar un archivo unidad.

Cuando la modificación de una unidad que tiene un enlace simbólico (symlink) apuntando a esa unidad, por ejemplo como lo hace la display-manager.service -> prefdm.service, el enlace simbólico debe copiarse en lugar de la unidad verdadera como en display-manager.service debe copiarse en el directorio /etc/systemd/system o una nueva unidad creada con .includes que lleve ese nombre.

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog: