.png)
Existen múltiples razones para tener que cambiar el nombre de un servicio systemd en producción. Por ejemplo:
- para diferenciarlo mejor de uno nuevo
- porque tu jefe lo ordenó
- debido a scripts heredados
- ...
Suponiendo un nuevo servicio genérico creado /etc/systemd/system/foo.service
, habilitado e iniciado de la siguiente manera: [1]
systemctl daemon-reload
systemctl enable --now foo
Luego, es posible que desees cambiarle el nombre de foo.service
a bar.service
sin afectar el proceso relacionado de ninguna manera.
En circunstancias normales puedes hacer algo como esto:
mv foo.service bar.service
systemctl daemon-reload
systemctl disable foo
systemctl enable bar
Entonces obtienes:
systemctl status foo
:running
not-found
disabled
systemctl status bar
:not-running
enabled
Entonces es posible que desees arreglarlo con:
systemctl stop foo
systemctl start bar
O con un reinicio. Sin embargo, en entornos de producción esto no es factible ya que no desea detener la aplicación para dicho cambio. Además, los reinicios se programan después de meses o años. Al mismo tiempo, es arriesgado mantener durante mucho tiempo un servicio detenido, ya bar
que no debe iniciarse por error antes de detener la ejecución del servicio no encontrado foo
.
En breve. ¿Qué enfoque utilizaría para cambiar el nombre de un servicio systemd en producción?
La condición ideal sería que los dos servicios fueran compatibles con versiones anteriores. Así, al detenerse foo
también se detiene bar
y viceversa.
Respuesta1
Puede que exista algún método mejor que desconozco, pero esto me viene a la mente como una solución alternativa que principalmente le brinda lo que necesita hasta que tenga la oportunidad de reiniciar el servicio:
- Cree un enlace simbólico con el nuevo nombre deseado que apunte al archivo de servicio existente (y
systemctl daemon-reload
).
sistemadtrata los enlaces simbólicos a unidades como aliasen lugar de unidades separadas, lo que significa que ambos nombres ahora se referirán a la misma unidad (mismo estado, mismo todo). - Planifique reemplazar el servicio durante su próxima ventana de mantenimiento.