
Tengo las siguientes unidades:
test_socket_activation.socket
[Unit]
Description="************** MY TEST SOCKET ***************"
PartOf=test_socket_activation.service
[Socket]
ListenStream=127.0.0.1:9991
[Install]
WantedBy=sockets.target
test_socket_activation.servicio
[Unit]
Description="********** MY TEST SERVICE *****************"
[Service]
ExecStart=/home/xxx/sysadmin/systemd_units/socket_based_activation/testservice.sh
[Install]
WantedBy=multi-user.target
serviciodeprueba.sh
#!/bin/bash
echo "Socket Service Triggered" > output.txt
En teoría, systemd debería estar escuchando en el puerto 127.0.0.1 9991 (a través de test_scocket_activation.socket). Cuando se accede al socket, systemd debe llamar a la unidad principal (test_scocket_activation.service), que a su vez debe ejecutar el script enumerado en la directiva ExecStart (testservice.sh), que luego creará un archivo de texto llamado output.txt para notificar que el Se ha accedido al enchufe.
Esto funciona como se esperaba (es decir, se crea output.txt cuando se accede al socket), excepto que la unidad de servicio (test_scocket_activation.service) falla después debido a que "la solicitud de inicio se repite demasiado rápido y se niega a iniciar" aunque solo se accede al socket una vez. . El fallo del servicio provoca entonces un fallo del socket asociado, que deja de escuchar.
Hice algunas pruebas, aquí están mis pasos y registré los resultados:
❯ sudo systemctl inicio test_socket_activation.socket
❯ sudo systemctl estado test_socket_activation.socket
● test_socket_activation.socket - "************** MY TEST SOCKET ***************"
Loaded: loaded (/etc/systemd/system/test_socket_activation.socket; disabled)
Active: active (listening) since Thu 2020-03-19 14:08:40 +01; 17s ago
Listen: 127.0.0.1:9991 (Stream)
Mar 19 14:08:40 toshi systemd[1]: Starting "************** MY TEST SOCKET ***************".
Mar 19 14:08:40 toshi systemd[1]: Listening on "************** MY TEST SOCKET ***************".
❯ eco "hola" | netcat 127.0.0.1 9991
❯ ls
output.txt testservice.sh
❯ sudo systemctl estado test_socket_activation.service
● test_socket_activation.service - "********** MY TEST SERVICE *****************"
Loaded: loaded (/etc/systemd/system/test_socket_activation.service; disabled)
Active: failed (Result: start-limit) since Thu 2020-03-19 14:10:42 +01; 9min ago
Process: 2842 ExecStart=/home/mkr/sysadmin/systemd_units/socket_based_activation/testservice.sh (code=exited, status=0/SUCCESS)
Main PID: 2842 (code=exited, status=0/SUCCESS)
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: test_socket_activation.service start request repeated too quickly, refusing to start.
Mar 19 14:10:42 toshi systemd[1]: Failed to start "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Unit test_socket_activation.service entered failed state.
❯ sudo systemctl estado test_socket_activation.socket
● test_socket_activation.socket - "************** MY TEST SOCKET ***************"
Loaded: loaded (/etc/systemd/system/test_socket_activation.socket; disabled)
Active: failed (Result: service-failed-permanent) since Thu 2020-03-19 14:10:42 +01; 41s ago
Listen: 127.0.0.1:9991 (Stream)
Mar 19 14:08:40 toshi systemd[1]: Starting "************** MY TEST SOCKET ***************".
Mar 19 14:08:40 toshi systemd[1]: Listening on "************** MY TEST SOCKET ***************".
Mar 19 14:10:42 toshi systemd[1]: Unit test_socket_activation.socket entered failed state.
❯ sudo journalctl -u test_socket_activation.service
-- Logs begin at Thu 2020-03-19 14:05:23 +01, end at Thu 2020-03-19 14:17:29 +01. --
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: Started "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Starting "********** MY TEST SERVICE *****************"...
Mar 19 14:10:42 toshi systemd[1]: test_socket_activation.service start request repeated too quickly, refusing to start.
Mar 19 14:10:42 toshi systemd[1]: Failed to start "********** MY TEST SERVICE *****************".
Mar 19 14:10:42 toshi systemd[1]: Unit test_socket_activation.service entered failed state.
Como puede ver arriba, se accede al socket solo UNA VEZ, el servicio se activa y solicita el script para crear el archivo output.txt. Pero poco después el servicio falla al intentar iniciarse varias veces.
Mis preguntas son las siguientes:
¿Por qué el servicio se inicia más de una vez, cuando solo se accede al socket una vez (a través de echo "hello" | netcat 127.0.0.1 9991)?
¿Cómo puedo evitar que el servicio se inicie varias veces cuando solo se accede una vez al socket asociado?
Todas las respuestas/aportes/ideas serán muy apreciadas, gracias.
Respuesta1
Ha creado un Accept=No
socket, donde al servicio se le pasa el descriptor del archivo del socket de escucha y se espera que acepte las conexiones, ysigue corriendo. La señal debería ser que no creó una unidad de servicio de plantilla, como habría sido necesaria para un Accept=Yes
socket donde el servicio pasa el descriptor del archivo de socket conectado.
Otras lecturas
- Jonathan de Boyne Pollard (2019).
tcp-socket-accept
. Guía de comida. Softwares. - https://unix.stackexchange.com/a/513663/5132
s6-tcpserver4d
. Laurent Bercot. redes s6. skarnet.org.