
Tengo un programa que, cuando se le da SIGUSR2, se bifurca y crea un nuevo proceso con gracia (pasando todos los sockets principales existentes al hijo y eliminando al padre), sin tiempo de inactividad, por lo que normalmente sin systemd sería algo como esto:
cp newbinary coredns
kill -s USR2 oldpid
Systemd solo tiene ExecReload
lo que de acuerdo con estorespuesta
En otras palabras, systemd quiere que solo implemente "recargar" si el servicio subyacente admite una verdadera funcionalidad de recarga... es decir, una recarga que no finaliza ni reinicia el servicio, ni hace que el servicio cambie su PID. En otras palabras, systemd sólo quiere reflejar qué características existen.
¿Puede ser algo como esto en el archivo systemd?
PIDFile=/tmp/coredns.pid
Type=forking
ExecStart=./coredns -pidfile /tmp/coredns.pid
ExecStop=kill `/tmp/coredns.pid`
ExecReload=/bin/kill -s USR2 `cat /tmp/coredns.pid`
La pregunta es, al hacer sudo systemctl reload coredns
, systemd:
- ¿Sabes que pid cambió?
- ¿Sigues manejando correctamente la supervisión de registros y procesos?
Respuesta1
Ok, forking
o oneoff
se atascará al iniciar, el tipo debería ser simple
, funcionaría correctamente:
echo '[Unit]
Description=Custom CoreDNS DNS server
After=network.target
[Service]
PermissionsStartOnly=true
LimitNOFILE=1048576
LimitNPROC=512
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
WorkingDirectory=/tmp/1
Type=simple
RemainAfterExit=yes
ExecStart=/tmp/1/start.sh
ExecStop=/tmp/1/kill.sh
ExecReload=/tmp/1/reload.sh
Restart=on-failure
[Install]
WantedBy=multi-user.target
' | sudo tee /usr/lib/systemd/system/coredns.service
sudo systemctl daemon-reload
crear guiones:
mkdir -p /tmp/1
echo '#!/usr/bin/bash
kill -s USR2 `cat /tmp/1/coredns.pid`
' > /tmp/1/reload.sh
echo '#!/usr/bin/bash
kill -s USR2 `cat /tmp/1/coredns.pid`
' > /tmp/1/kill.sh
echo '#!/usr/bin/bash
/tmp/1/coredns -pidfile /tmp/1/coredns.pid -conf=/tmp/1/Corefile
' > /tmp/1/start.sh
chmod a+x /tmp/1/*.sh
chmod 777 /tmp/1 # just so that no need to set user permission on systemd
cp Corefile coredns /tmp/1/
se puede iniciar correctamente:
sudo systemctl start coredns
# on journalctl:
Apr 20 18:50:06 pop2204 systemd[1]: Started Custom CoreDNS DNS server.
Apr 20 18:50:06 pop2204 start.sh[1553313]: whoami Name called
Apr 20 18:50:06 pop2204 start.sh[1553313]: whoami Name called
Apr 20 18:50:06 pop2204 start.sh[1553313]: whoami Name called
Apr 20 18:50:06 pop2204 start.sh[1553313]: .:1053
Apr 20 18:50:06 pop2204 start.sh[1553313]: CoreDNS-1.9.4
Apr 20 18:50:06 pop2204 start.sh[1553313]: linux/amd64, go1.20.3, 81159d2f-dirty
elimine el binario antiguo (porque el archivo de texto está ocupado si se copia directamente), luego copie el binario nuevo
rm /tmp/1/coredns
cp coredns /tmp/1/coredns
sudo systemctl reload coredns
# from journalctl:
Apr 20 18:52:03 pop2204 systemd[1]: Reloading Custom CoreDNS DNS server...
Apr 20 18:52:03 pop2204 start.sh[1553313]: [INFO] SIGUSR2: Upgrading
Apr 20 18:52:03 pop2204 start.sh[1553313]: [INFO] Upgrading
Apr 20 18:52:03 pop2204 systemd[1]: Reloaded Custom CoreDNS DNS server.
Apr 20 18:52:03 pop2204 start.sh[1553726]: whoami Name called 2
Apr 20 18:52:03 pop2204 start.sh[1553726]: whoami Name called 2
Apr 20 18:52:03 pop2204 start.sh[1553726]: whoami Name called 2
Apr 20 18:52:03 pop2204 start.sh[1553726]: .:1053
Apr 20 18:52:03 pop2204 start.sh[1553313]: [INFO] Upgrade finished
Apr 20 18:52:03 pop2204 start.sh[1553726]: CoreDNS-1.9.4
Apr 20 18:52:03 pop2204 start.sh[1553726]: linux/amd64, go1.20.3, 81159d2f-dirty