.png)
Es gibt mehrere Gründe, einen systemd-Dienst in der Produktion umbenennen zu müssen. Zum Beispiel:
- um es besser von einem neuen zu unterscheiden
- weil dein Chef es angeordnet hat
- wegen veralteter Skripte
- ...
Angenommen, ein neuer generischer Dienst wird erstellt /etc/systemd/system/foo.service
, aktiviert und wie folgt gestartet: [1]
systemctl daemon-reload
systemctl enable --now foo
Anschließend möchten Sie es möglicherweise von foo.service
in umbenennen bar.service
, ohne den zugehörigen Prozess in irgendeiner Weise zu beeinträchtigen.
Normalerweise können Sie einfach Folgendes tun:
mv foo.service bar.service
systemctl daemon-reload
systemctl disable foo
systemctl enable bar
Dann erhalten Sie:
systemctl status foo
:running
not-found
disabled
systemctl status bar
:not-running
enabled
Sie können das Problem also wie folgt beheben:
systemctl stop foo
systemctl start bar
Oder mit einem Neustart. In Produktionsumgebungen ist dies jedoch nicht praktikabel, da Sie die Anwendung für eine solche Änderung nicht stoppen möchten. Außerdem sind Neustarts nach Monaten oder Jahren geplant. Gleichzeitig ist es riskant, einen gestoppten Dienst so lange beizubehalten, dass er nicht bar
versehentlich gestartet werden sollte, bevor der nicht gefundene Dienst gestoppt wird foo
.
Kurz gesagt. Welchen Ansatz würden Sie verwenden, um einen systemd-Dienst in der Produktion umzubenennen?
Der Idealzustand wäre, wenn beide Dienste abwärtskompatibel wären. Das heißt, wenn sie gestoppt werden, foo
werden sie auch gestoppt bar
und umgekehrt.
Antwort1
Es gibt möglicherweise eine bessere Methode, die ich nicht kenne, aber dies fällt mir als Workaround ein, mit dem Sie im Großen und Ganzen das bekommen, was Sie brauchen, bis Sie die Möglichkeit haben, den Dienst neu zu starten:
- Erzeugen Sie einen Symlink mit dem gewünschten neuen Namen, der auf die bestehende Servicedatei (und
systemctl daemon-reload
) verweist.
Systemdbehandelt Symlinks zu Einheiten als Aliaseanstelle von getrennten Einheiten, was bedeutet, dass sich beide Namen jetzt auf dieselbe Einheit beziehen (gleicher Status, alles gleich). - Planen Sie, den Dienst während Ihres nächsten Wartungsfensters tatsächlich zu ersetzen.