Inicio » Linux » Systemd – Configuración de Servicios en RedHat

Systemd – Configuración de Servicios en RedHat

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email

La histórica configuración de /etc/init.d se está quedando obsoleta y en RedHat 7 / Centos 7 debemos utilizar systemctl (systemd) para personalizar aquellos procesos que queramos que arranquemos con el boot del sistema.

Configurar systemctl es muy sencillo. De hecho, creé un script para arrancar el Apache que hace que funcione este blog. Lo hice asi:

Configuración de un servicio básico con systemd

[[email protected] ~]# cat /usr/lib/systemd/system/httpd_puerto53.service
[Unit]
Description=Apache puerto53
After=network.target remote-fs.target nss-lookup.target

[Service]
ExecStart=/app/puerto53/scripts/Apache/apache_puerto53.sh start
ExecStop=/app/puerto53/scripts/Apache/apache_puerto53.sh stop
Type=forking
PIDFile=/app/puerto53/httpd/run/httpd/httpd.pid

[Install]
WantedBy=multi-user.target
[[email protected] ~]#

Arranque del servicio

Veamos cómo funciona:

[[email protected] system]# systemctl enable httpd_puerto53.service
[[email protected] system]# systemctl start httpd_puerto53.service
[[email protected] system]# ps -ef |grep -i http
root 4732 1 0 12:28 ? 00:00:00 /usr/bin/sh /etc/init.d/httpd_puerto53 start
root 4734 1 1 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4736 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4737 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4738 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4739 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4740 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4741 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4742 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4743 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4744 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4745 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4746 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4747 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4748 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4749 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4750 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
puerto53 4751 4734 0 12:28 ? 00:00:00 httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
root 4756 2794 0 12:28 pts/0 00:00:00 grep --color=auto -i http

Comprobar el estado del servicio

[[email protected] system]# systemctl status httpd_puerto53.service
● httpd_puerto53.service - Apache puerto53
Loaded: loaded (/etc/systemd/system/httpd_puerto53.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2018-08-16 12:28:46 CEST; 4s ago
Process: 4760 ExecStop=/etc/init.d/httpd_puerto53 stop (code=exited, status=0/SUCCESS)
Process: 4732 ExecStart=/etc/init.d/httpd_puerto53 start (code=exited, status=0/SUCCESS)
Main PID: 4732 (code=exited, status=0/SUCCESS)

Aug 16 12:28:41 prt53ws1 systemd[1]: Started Apache puerto53.
Aug 16 12:28:41 prt53ws1 systemd[1]: Starting Apache puerto53...
Aug 16 12:28:46 prt53ws1 httpd_puerto53[4732]: 4734 (process ID) old priority 0, new priority -19
[[email protected] system]#

Script de arranque y parada del servicio

Ya que estamos, os enseño el script que utilizo para parar y arrancar apache:

Lenovo IdeaPad 5 - Ordenador Portátil 15.6" FullHD (AMD Ryzen 5 5500U, 16GB RAM, 512GB...
  • Pantalla de 15.6" FullHD (1920x1080) 300nits
  • Procesador AMD Ryzen 5 5500U (6C/12T, 2.1 GHz/4.04GHz, 8 MB)
  • Memoria RAM de 16GB
[[email protected] ~]# cat /app/puerto53/scripts/Apache/apache_puerto53.sh
#!/usr/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

if [ $1 == «start» ]
then


 
httpd -f /app/puerto53/httpd/conf/httpd.conf -k start -D SSL
sleep 5
PID=`cat /app/puerto53/httpd/run/httpd/httpd.pid`
/usr/bin/renice -n -19 $PID

elif [ $1 == «stop» ]
then

httpd -f /app/puerto53/httpd/conf/httpd.conf -k stop

fi
[[email protected] ~]#

Entendiendo el funcionamiento de Systemd

Sección Service

  • Directiva Type:
    • simple: El proceso principal del servicio se especifica en la línea de inicio. Este es el valor por defecto si las directivas «Type=» y «Busname=» no están establecidas, pero el «ExecStart=» sí lo está.
    • forking: Este tipo de servicio se utiliza cuando se crea un proceso hijo. Esto le dice a systemd que el proceso sigue ejecutándose aunque el padre haya salido.
    • oneshot: Este tipo indica que el proceso durará poco tiempo y que el sistema debe esperar a que el proceso salga antes de continuar con otras unidades.
    • dbus: Algunas aplicaciones necesitan conectarse entre sí mediante el protocolo D-BUS.
    • notify: El servicio enviará una notificación cuando haya terminado de ponerse en marcha. El sistema esperará antes de continuar con el arranque de otros servicios.
    • idle: El servicio no funcionará hasta la finalización de todos los trabajos.
  • Directivas relacionadas con la ejecución de los procesos:
    • ExecStart: Indicamos el proceso que va a iniciar el servicio.
    • ExecStartPre: Antes de la ejecución del proceso inicial, ejecutamos otros comandos.
    • ExecStartPost: Al finalizar el proceso, ejecutamos otros comandos.
    • ExecReload: Volvemos a leer la configuración del servicio
    • ExecStop: Especificamos el comando para finalizar el proceso.
    • ExecStopPost: Ejecutamos algunos comandos después de finalizar el proceso.
    • Restart: Indicamos las circunstancias en que systemd reiniciará el proceso automáticamente: “always”, “on-success”, “on-failure”, “on-abnormal”, “on-abort”, or “on-watchdog”.
    • TimeoutSec: Especificamos el tiempo máximo que Systemd esperará antes de parar el servicio si ha sido marcado como «failed» o «forcefully killing it».
  • Directivas adicionales:
    • RemainAfterExit: Se suele utilizar conjuntamente con oneshot. Indica que el proceso debería ser considerado en ejecución, incluso, si ha devuelto un código de salida.
    • PIDFile: Si el servicio es de tipo forking el PID del proceso se almacenará en el fichero indicado en esta directiva.
    • BusName: Utilizaremos esta directiva para indicar el nombre del bus (D-BUS) al que se asociará el proceso cuando arranque.
    • NotifyAccess: Especificamos el acceso al socket que se debe usar para escuchar las notificaciones cuando se selecciona el tipo de servicio «notify». Este puede ser «none», «main» o «all». El valor predeterminado «none», ignora todos los mensajes de estado. La opción «main» escucha los mensajes del proceso principal y la opción «all» escucha todos los procesos del servicio.

Sección Socket

  • Las directivas más utilizadas:
    • ListenStream: Define una dirección TCP/IP para poder establecer una comunicación por red con el servicio.
    • ListenDatagram: Los servicios UDP utilizan este tipo de comunicación.
    • ListenSequentialPacket: Define la dirección de red para una comunicación secuencial. Si el dato enviado por red es muy grande, se envían varios paquetes de manera secuencial.
    • ListenFIFO: FiFo proviene de First In First Out o, lo primero que llega es lo primero que sale. Muchas aplicaciones utilizan este tipo de comunicación. Podemos definir un buffer de este tipo en vez de un socket.
  • Directivas de control de las comunicaciones:
    • Accept: Podemos definir si todas las comunicaciones las administrará una sola instancia o crearemos nuevas para repartir el tráfico entre ellas.
    • SocketUser: Definimos el usuario propietario del socket. Por defecto es el root.
    • SocketGroup: Definimos el grupo propietario del socket. Por defecto es root.
    • SocketMode: Definimos los permisos (de UNIX) para el socket.
    • Service: Podemos definir un nombre del servicio para el socket (MiServicio.socket).

Sección Mount

Mount está relacionado con los puntos de montaje de los filesystems, tal y como podemos ver en el fichero /etc/fstab.

HP Pavilion 15-eg0018ns - Ordenador Portátil de 15.6" FHD (Intel Core i7-1165G7, 16GB...
  • Pantalla Full HD de 15.6" (39,6 cm) en diagonal; IPS; bisel micro-edge; antirreflectante; 250 nits; 45 % NTSC (1920 x 1080)
  • Procesador Intel Core i7-1165G7 (hasta 4,7 GHz con tecnología Intel Turbo Boost, 12 MB de caché L3, 4 núcleos, 8 subprocesos)
  • Memoria RAM DDR4-3200 MHz de 16 GB
  • What: Indicamos el path del recurso que vamos a montar.
  • Where: Especificamos dónde vamos a montar el recurso (punto de montaje).
  • Type: Indicamos el tipo de filesystem. Por ejemplo, XFS.
  • Options: Opciones de montaje. Cada opción se separará con una coma.
  • SloppyOptions: Si está definido como true y hay una opción de montaje incorrecta, él recurso se montará igualmente con las opciones de montaje por defecto.
  • DirectoryMode: Si se necesitan crear directorios para poder montar el filesystem, indicaremos con qué permisos se crearán.
  • TimeoutSec: Especificamos el tiempo máximo de espera para montar el filesystem.

Sección Automount

Las dos únicas directivas importantes son Where y DirectoryMode, que ya hemos visto anteriormente.

Sección Swap

Las unidades o servicios de swap se configuran para montar filesystems de swap en el sistema. Lo podemos hacer mediante la configuración del fichero /etc/fstab o con la llamada de una unidad o servicio de systemd.

Las directivas relacionadas con esta sección son:

  • What: Indicamos el path absoluto del recurso de swap.
  • Priority: Definimos la prioridad con la que el espacio de swap debe ser creado.
  • Options: Especificamos las opciones de montaje del swap, separadas por comas.
  • TimeoutSec: El tiempo de espera en segundos para montar el swap antes de dar la operación por fallada.

Sección Path

Una unidad path se define para que Systemd pueda monitorizar los cambios o la actividad de un path del sistema. Debe existir otra unidad que se activará cuando se detecten cierta actividad. La actividad del path se notifica mediante eventos inotify.

Directivas de esta sección:

  • PathExists: Revisa si el path indicado existe.
  • PathExistsGlob: Igual que la anterior directiva pero soporta expresiones glob.
  • PathChanged: La unidad asociada se activa si se detecta algún cambio.
  • PathModified: Igual que la directiva anterior pero actúa en las escrituras en los archivos o cuando se ha cerrado uno.
  • DirectoryNotEmpty: Activa la unidad asociada cuando el directorio ya no está vacío.
  • Unit: Se especifica la unidad que se activará.
  • MakeDirectory: Definimos si Systemd creará la estructura de directorios antes de monitorizarla.
  • DirectoryMode: Si la directiva anterior está habilitada, configuraremos los permisos de los directorios creados.

Sección Timer

Podemos crear unidades o servicios que complementan a las tareas configuradas en cron para programar tareas o ejecutarlas si van con retraso.

  • OnActiveSec: Permite que la unidad asociada se active en relación con la activación de la unidad .timer.
  • OnBootSec: Especificamos el tiempo que pasará para que se active la unidad asocidad después de que el sistema se inicie.
  • OnStartUpSec: Similar al anterior pero se ejecuta unos segundos después de que el servicio Systemd se haya iniciado.
  • OnUnitActiveSec: Se configura un temporizador en relación a la última vez en que la unidad asociada fue ejecutada.
  • UnitInactiveSec: Se configura un temporizador en relación a la última vez en que la unidad asociada se marcó como inactiva.
  • OnCalendar: Podemos definir una fecha y hora exactas para ejecutar la unidad asociada.
  • AccuracySec: Especificamos la precisión del temporizador. Por ejemplo, la unidad asociada se activará en un plazo de un minuto desde que se alcanza el temporizador.
  • Unit: Indicamos la unidad que debe ser activada cuando alcancemos el temporizador.
  • Persistent: Si se configura, systemd activará la unidad asociada cuando el temporizador se active si se hubiera activado durante el período en que el temporizador estuvo inactivo.
  • WakeSystem: Permite despertar un sistema de suspensión si se alcanza el temporizador cuando está en ese estado.

Esperar el arranque de un servicio antes de montar un filesystem

Algunos filesystems como, por ejemplo, Stratis necesitan que esté arrancado un servicio para poder ser montados. Para ello, y siguiendo con el ejemplo de Stratis, configuraremos el fstab de la siguiente manera:

/dev/test_stratis /stratis xfs defaults,x-systemd.requires=stratisd.service 0 0
About Author

¿Te ha gustado? Compártelo

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email

Contenido Relacionado

Artículos Recientes

Deja un comentario