☰

Как переименовать службу systemd, не затрагивая процесс (без остановки/перезапуска)

tag-icon • tag-icon systemd
Как переименовать службу systemd, не затрагивая процесс (без остановки/перезапуска)

Существует множество причин переименовывать службу systemd в продакшене. Например:

  • чтобы лучше отличить его от нового
  • потому что твой босс приказал это
  • из-за устаревших скриптов
  • ...

Предположим, что новая универсальная служба создана, включена /etc/systemd/system/foo.serviceи запущена следующим образом: [1]

systemctl daemon-reload
systemctl enable --now foo

Затем вы можете переименовать его из foo.serviceв , bar.serviceне влияя каким-либо образом на связанный с ним процесс.

В обычных обстоятельствах вы можете просто сделать что-то вроде этого:

mv foo.service bar.service
systemctl daemon-reload
systemctl disable foo
systemctl enable  bar

Тогда вы получите:

  • systemctl status foo:running not-found disabled
  • systemctl status bar:not-running enabled

Поэтому вы можете исправить это с помощью:

systemctl stop  foo
systemctl start bar

Или с перезагрузкой. Однако в производственных средах это нецелесообразно, так как вы не хотите останавливать приложение для такого изменения. Кроме того, перезагрузки планируются через месяцы или годы. В то же время рискованно долго держать остановленную службу, такую ​​как barэта, не должна быть запущена по ошибке до остановки ненайденного работающего foo.

Короче говоря. Какой подход вы бы использовали для переименования службы systemd в продакшене?

Идеальным условием было бы иметь обратную совместимость двух служб. Таким образом, остановка fooтакже останавливает barи наоборот.

решение1

Возможно, есть какой-то лучший метод, о котором я не знаю, но это приходит на ум как обходной путь, который в большинстве случаев даст вам то, что нужно, пока у вас не появится возможность перезапустить службу:

  1. Создайте символическую ссылку с желаемым новым именем, которая указывает на существующий файл службы (и systemctl daemon-reload).
    Systemdрассматривает символические ссылки на юниты как псевдонимывместо отдельных единиц, что означает, что оба названия теперь будут относиться к одной и той же единице (одинаковый статус, всё одинаковое).
  2. Запланируйте фактическую замену услуги во время следующего периода технического обслуживания.

Связанный контент