Article ID: 124440, created on May 29, 2015, last review on May 29, 2015

  • Applies to:
  • Operations Automation
  • Plesk
  • Virtuozzo
  • Virtuozzo containers

En este artículo se explica qué es systemd, se proporciona información básica acerca de sus comandos y su configuración y se detallan los productos de Odin que soportan systemd.

Introducción

systemd es un servicio de inicialización del sistema. Este inicia servicios cuando arranca el servidor Linux y los detiene cuando se apaga el servidor.

systemd reemplaza los sistemas de inicialización SysV y Upstart en CentOS a partir de CentOS 7. Asimismo, systemd es el sistema de inicialización predeterminado en las distribuciones más recientes de Linux − openSUSE, Ubuntu y Fedora. Debian utilizará systemd de forma predeterminada a partir de Debian 8 (Jessie).

En comparación con otros sistemas de inicialización, las ventajas más destacadas de systemd son las siguientes:

  • Compatibilidad con versiones anteriores de SysV init. Esto significa que los scripts presentes en /etc/init.d y los comandos como telinit, service y chkconfig siguen funcionando correctamente.
  • Inicio paralelo de los servicios. Este permite iniciar system de forma mucho más rápida.
  • Mecanismo de resolución correcta de dependencia de servicios. Los administradores de sistemas y los responsables del mantenimiento de los paquetes no deben configurar de forma manual el orden en el que init inicia los servicios. systemd calcula las dependencias e inicia los servicios en el orden adecuado.
  • Activación de D-Bus. Los servicios que utilizan el protocolo D-Bus para las comunicaciones entre procesos pueden iniciarse bajo petición cuando el la aplicación cliente intenta conectar con el servicio.
  • Activación basada en sockets. systemd escucha en los sockets de los servicios y transfiere dichos sockets a los servicios cuando estos se inician. Como resultado, los servicios no pierden mensajes ni paquetes enviados durante el reinicio, puesto que systemd copia en caché aquellos mensajes que no pueden entregarse al servicio.

Terminología

systemd utiliza la siguiente terminología:

  • Units − Unidades de configuración de systemd. Las unidades pueden representar servicios, destinos (vea a continuación), puntos de montaje, dispositivos, rutas vistas para cambios, instantáneas, etc.

  • Targets − Recopilación de unidades. Los destinos son lo análogos de los niveles de ejecución en SysV init, si bien puede haber más de 7 y pueden activarse varios destinos a la vez. Cuando se activa un destino, las unidades presentes en este también son activadas.

Comandos

systemctl

La gestión de systemd y su configuración se efectúa mediante el comando systemctl. A continuación puede ver algunos de los comandos usados con más frecuencia:

  • Inicio del servicio:

    # systemctl start nginx

  • Comprobar el estado del servicio con la información sobre el archivo en el que se ha definido el servicio, el estado del servicio y la traza de los comandos con códigos de salida:

    # systemctl status nginx

  • Ver si se ha iniciado el servicio:

    # systemctl is-active nginx

  • Reiniciar el servicio:

    # systemctl restart nginx

  • Detener el servicio:

    # systemctl stop nginx

  • Activar el servicio (análogo de "chkconfig nginx on"):

    # systemctl enable nginx

  • Listar todos los servicios (análogo de "chkconfig --list"):

    # systemctl list-units --type=service --all

  • Listar todos los destinos disponibles:

    # systemctl list-units --type=target --all

  • Activar un destino (iniciar las unidades dentro de dicho destino)

    # systemctl enable graphical.target

  • Cambiar al destino (detener todos los demás destinos excepto el deseado (análogo de cambiar a un nivel de ejecución con telinit):

    # systemctl isolate emergency.target

journalctl

Otro comando que puede resultarle de utilidad es journalctl, que permite efectuar consultas a los registros de systemd. Los comandos más útiles son los siguientes:

  • Lista continuada de todos los mensajes de registro del servicio nginx (funciona como "tail -f"):

    # journalctl -f -u nginx

  • Listar los últimos 10 mensajes presentes en el registro de systemd con descripciones de estado ampliadas:

    # journalctl -xn

  • Mostrar todos los registros generados por el ejecutable httpd:

    # journalctl /usr/sbin/httpd

Ejemplo

A continuación le mostramos un ejemplo de la salida de systemctl cuando no se inicia nginx debido a que otro proceso escucha al puerto 80:

[root@plesk-12 ~]# systemctl start nginx
Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.

[root@plesk-12 ~]# systemctl status nginx
nginx.service - Startup script for nginx service
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Fri 2015-02-06 03:55:27 EST; 21s ago
  Process: 1933 ExecStopPost=/bin/echo Service nginx stopped (code=exited, status=0/SUCCESS)
  Process: 1852 ExecStartPost=/bin/echo Service nginx started (code=exited, status=0/SUCCESS)
  Process: 2011 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
  Process: 2008 ExecStartPre=/usr/sbin/nginx -q -t (code=exited, status=0/SUCCESS)
  Process: 2005 ExecStartPre=/usr/bin/test $NGINX_ENABLED = yes (code=exited, status=0/SUCCESS)
  Process: 2002 ExecStartPre=/bin/echo Starting nginx service (code=exited, status=0/SUCCESS)
 Main PID: 1850 (code=exited, status=0/SUCCESS)

Feb 06 03:55:25 plesk-12 echo[2002]: Starting nginx service
Feb 06 03:55:25 plesk-12 nginx[2011]: nginx: [emerg] bind() to 10.39.3.27:80 failed (98: Address already in use)
Feb 06 03:55:25 plesk-12 nginx[2011]: nginx: [emerg] bind() to 10.39.3.27:80 failed (98: Address already in use)
Feb 06 03:55:26 plesk-12 nginx[2011]: nginx: [emerg] bind() to 10.39.3.27:80 failed (98: Address already in use)
Feb 06 03:55:26 plesk-12 nginx[2011]: nginx: [emerg] bind() to 10.39.3.27:80 failed (98: Address already in use)
Feb 06 03:55:27 plesk-12 nginx[2011]: nginx: [emerg] bind() to 10.39.3.27:80 failed (98: Address already in use)
Feb 06 03:55:27 plesk-12 nginx[2011]: nginx: [emerg] still could not bind()

Esta salida del comando de estado es suficiente para determinar la causa del problema.

Archivos de configuración

Ubicación

Los archivos de configuración se encuentran en los siguientes directorios:

  • /etc/systemd/system – Directorio que contiene las unidades creadas por el administrador del sistema. Las unidades presentes en este directorio son las que prevalecen sobre las unidades encontradas en otros directorios.
  • /run/systemd/system – Directorio que contiene las unidades creadas por systemd o por los servicios durante runtime.
  • /usr/lib/systemd/system – Directorio que contiene las unidades instaladas mediante paquetes RPM/DEB. Estas unidades pueden ser invalidadas por las unidades presentes en /run/systemd/system y /etc/systemd/system.

Estructura

Los servicios se configuran en archivos *.service, que en el contexto de systemd actúan de igual forma que los scripts rc en SysV (por ejemplo, /etc/init.d/nginx), pero son más fáciles de escribir y entender.

A continuación puede ver el archivo para el servidor web nginx con comentarios adicionales. Si desea más información acerca de la estructura de este archivo y de las opciones disponibles, haga clic aquí.

[Unit]
Description=Startup script for nginx service       
Requires=nss-lookup.target remote-fs.target  # These targets must be enabled for this service
After=nss-lookup.target remote-fs.target  # Start after these targets

[Service]
Type=forking  # Tells systemd how the service starts. In this case the command 
              # configured in ExecStart below will fork the service process 
              # and exit.
Restart=no    # Don't try to restart the service if it didn't start properly.

PIDFile=/var/run/nginx.pid
GuessMainPID=no

Environment=NGINX_ENABLED=no
Environment=NGINX_PID_FILE=/var/run/nginx.pid
EnvironmentFile=/etc/sysconfig/nginx  # Analog of ". /etc/sysconfig/nginx" in rc script

.include /etc/sysconfig/nginx.systemd

# These are executed when service starts
ExecStartPre=/bin/echo 'Starting nginx service'
ExecStartPre=/usr/bin/test $NGINX_ENABLED = "yes"
ExecStartPre=/usr/sbin/nginx -q -t
ExecStart=/usr/sbin/nginx
ExecStartPost=/bin/echo "Service nginx started"

# These - when it reloads
ExecReload=/bin/echo "Reloading nginx service"
ExecReload=/usr/bin/test $NGINX_ENABLED = "yes"
ExecReload=/usr/sbin/nginx -q -t
ExecReload=/usr/bin/pkill -F ${NGINX_PID_FILE} --signal HUP

# And this - when it stops.
# You may have noticed that we have only 'echo' command here.
# This is because systemd takes care of shutting down the process.
ExecStopPost=/bin/echo 'Service nginx stopped'

[Install]
WantedBy=multi-user.target  # Which target to start this service with.

systemd y productos de Odin

Plesk

Plesk soporta systemd a partir de la versión 11.5 (en sistemas openSUSE) y de la versión 12 (en CentOS).

Los servicios de Plesk (psa, nginx, sw-engine) son gestionados por systemd de la misma forma que los demás servicios. Los archivos de configuración de los servicios se encuentran en el directorio /usr/lib/systemd/system/ .

Los mensajes de los servicios, que generalmente suelen ser recopilados por el servicio syslogd, son recopilados por systemd-journald y pueden examinarse ejecutando el comando journalctl, así como en los archivos presentes en el directorio /var/log/.

Los servicios de Plesk no se recopilan en un destino especial y se inician junto con multi-user.target, el destino predeterminado para instalaciones de servidor.

Virtuozzo y Virtuozzo containers

En estos momentos, en CentOS 7 no es posible instalar Virtuozzo ni Virtuozzo containers (anteriormente denominados Parallels Cloud Server y Paralells Virtuozzo Containers, respectivamente), ya que estos productos no soportan systemd. De todos modos, aquellos sistemas operativos preparados para systemd pueden instalarse en máquinas virtuales y contenedores.

Service Automation y Plesk Automation

Actualmente, Service Automation y Plesk Automation (anteriomente denominados Parallels Automation y Parallels Plesk Automation, respectivamente) no soportan CentOS 7 en sus nodos de infraestructura y servicios.

d02f9caf3e11b191a38179103495106f 2897d76d56d2010f4e3a28f864d69223 e0aff7830fa22f92062ee4db78133079 caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae 614fd0b754f34d5efe9627f2057b8642 0dd5b9380c7d4884d77587f3eb0fa8ef a914db3fdc7a53ddcfd1b2db8f5a1b9c 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article
Save as PDF