☰

Cómo cambiar el nombre de un servicio systemd sin afectar el proceso (sin detener/reiniciar)

tag-icon • tag-icon systemd
Cómo cambiar el nombre de un servicio systemd sin afectar el proceso (sin detener/reiniciar)

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.servicea bar.servicesin 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 barque 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 footambién se detiene bary 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:

  1. 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).
  2. Planifique reemplazar el servicio durante su próxima ventana de mantenimiento.

información relacionada