.png)
Существует множество причин переименовывать службу 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
Возможно, есть какой-то лучший метод, о котором я не знаю, но это приходит на ум как обходной путь, который в большинстве случаев даст вам то, что нужно, пока у вас не появится возможность перезапустить службу:
- Создайте символическую ссылку с желаемым новым именем, которая указывает на существующий файл службы (и
systemctl daemon-reload
).
Systemdрассматривает символические ссылки на юниты как псевдонимывместо отдельных единиц, что означает, что оба названия теперь будут относиться к одной и той же единице (одинаковый статус, всё одинаковое). - Запланируйте фактическую замену услуги во время следующего периода технического обслуживания.