Există mai multe motive pentru a fi nevoit să redenumească un serviciu systemd în producție. De exemplu:
- pentru a o diferenția mai bine de una nouă
- pentru că șeful tău a comandat-o
- din cauza scripturilor moștenite
- ...
Presupunând un nou serviciu generic creat în /etc/systemd/system/foo.service și activat și pornit după cum urmează: [1]
systemctl daemon-reload
systemctl enable --now foo
Apoi, poate doriți să-l redenumiți de la foo.service la bar.serviciu fără a afecta în vreun fel procesul aferent.
În circumstanțe normale, puteți face ceva de genul acesta:
mv foo.service bar.service
systemctl daemon-reload
systemctl dezactivați foo
bara de activare systemctl
Apoi obțineți:
systemctl status foo: alergare nu a fost gasit dezactivatbara de stare systemctl: nu alearga activat
Deci, poate doriți să remediați cu:
systemctl stop foo
bara de pornire systemctl
Sau cu un reboot. Cu toate acestea, în mediile de producție, acest lucru nu este fezabil, deoarece nu doriți să opriți aplicația pentru o astfel de modificare. În plus, repornirile sunt programate după luni sau ani. În același timp, este riscant să păstrezi mult timp un serviciu oprit ca bar care nu trebuie pornit din greșeală înainte de a opri alergarea negăsită foo.
Pe scurt. Ce abordare ați folosi pentru a redenumi un serviciu systemd în producție?
Condiția ideală ar fi ca cele două servicii să fie retrocompatibile. Astfel, oprirea foo se opreste de asemenea bar si invers.
