Der richtige Ersatz für Rc.local in Systemd, anstatt Rc.local neu zu erstellen?

Ich kann nicht den richtigen Weg finden, um einige lokale auszuführen Skripte (oder sehr lokale Befehle) bei systemd, ich weiß bereits, dass ich keinen Dienst (in systemd eine Unit) für diese Art von Skripten erstellen darf (oder muss?) ….

Die Problemumgehung, die ich gefunden habe, besteht darin, rc.local zu erstellen und ihr Ausführungsberechtigungen zu erteilen.

printf '#!/bin/bash nnexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

Wenn ich zum Beispiel einen Legacy-Server mit einem einfachen von Ihnen konfigurierten rc.local bekomme, weiß ich, was Sie getan haben und wie sehr es weh tun wird, etwas Neues auf der Distribution zu aktualisieren oder zu installieren, da rc.local von extern respektiert wurde Pakete, aber andererseits, wenn ich einen Server installiere und eine oder zwei oder drei systemd-Units (oder sogar sysvinit-Dienste) erstelle, nur um eine einfache Aufgabe zu erledigen, kann das manchmal Ihr Leben schwerer machen, und noch viel mehr als diese meine Units Namen können eines Tages mit den Namen der neuen Dienste kollidieren, die von der Distributionsentwicklung erstellt und möglicherweise bei einem Upgrade installiert werden, was Probleme für meine Skripte verursacht!

Ich sehe eine andere Frage nach wo ist rc.local fragen und die Antwort war, es zu erstellen und Ausführungsberechtigungen zu erteilen, ich denke, meine Frage ist wirklich nicht ein Duplikat , weil ich nicht wissen will, wo es ist – glauben Sie mir, ich will nur akzeptieren dass es veraltet ist , aber ich kann nicht den richtigen Weg finden, um solche Dinge zu tun, sollte ich wirklich eine Einheit nur für solche einfachen Dinge erstellen?

Akzeptierte Antwort:

Wie an anderer Stelle ausgeführt, wird es etwas unsauber, rc-local.service zu verwenden unter systemd .

1. Es ist theoretisch möglich, dass Ihre Distribution dies nicht ermöglicht. (Ich denke, das ist nicht üblich, z. B. weil das Deaktivieren derselben Build-Option auch poweroff entfernt / reboot Befehle, die viele Leute verwenden).
2. Die Semantik ist nicht ganz klar. Systemd definiert rc-local.service eine Möglichkeit, aber Debian bietet eine Drop-In-Datei, die mindestens eine wichtige Einstellung ändert.

rc-local.service kann oft gut funktionieren. Wenn Sie sich wegen der oben genannten Punkte Sorgen machen, brauchen Sie nur Ihre eigene Kopie davon zu erstellen! Hier ist die Magie:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

Ich glaube nicht, dass Sie jedes einzelne Detail verstehen müssen[*], aber es gibt zwei Dinge, die Sie hier wissen müssen.

1. Sie müssen dies mit systemctl enable my-startup.service aktivieren .

2. Wenn Ihr Skript von einem anderen Dienst abhängig ist, einschließlich network-online.target , müssen Sie es deklarieren. Z.B. fügen Sie eine [Unit] hinzu mit den Zeilen Wants=network-online.target und After=network-online.target .

   Sie müssen sich keine Gedanken über Abhängigkeiten von „Early Boot“-Diensten machen – insbesondere Dienste, die bereits vor basic.target bestellt wurden . Dienste wie my-startup.service werden automatisch nach basic.target geordnet , es sei denn, sie setzen DefaultDependencies=no .

   Wenn Sie sich nicht sicher sind, ob eine Ihrer Abhängigkeiten ein „Early Boot“-Dienst ist, besteht ein Ansatz darin, die Dienste aufzulisten, die vor basic.target bestellt werden , indem Sie systemctl list-dependencies --after basic.target ausführen . (Beachten Sie, dass dies --after ist , nicht --before ).

Verwandt:Skript erneut ausführen, wenn Eingabe ja ist?

Es gibt einige Überlegungen, die meiner Meinung nach auch auf pre-systemd rc.local zutreffen :

1. Sie müssen sicherstellen, dass Ihre Befehle nicht mit einem anderen Programm in Konflikt stehen, das versucht, dasselbe zu steuern.
2. Es ist am besten, langlaufende Programme, auch bekannt als Daemons, nicht aus rc.local zu starten .

[*] Ich habe Type=oneshot verwendet + RemainAfterExit=yes weil es für die meisten One-Shot-Skripte sinnvoller ist. Es formalisiert, dass Sie eine Reihe von Befehlen ausführen, nämlich my-startup als „aktiv“ angezeigt wird, sobald sie abgeschlossen sind, und dass Sie keinen Daemon starten werden.