Ich kann auf systemd einige lokale Skripte (oder sehr lokale Befehle) nicht korrekt ausführen. Ich weiß bereits, dass ich keinen Dienst (in systemd eine Einheit) für diese Art von Skripten erstellen darf (oder muss ich?).

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

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

Wenn ich zum Beispiel einen Legacy-Server mit einer von Ihnen konfigurierten einfachen rc.local bekomme, weiß ich, was Sie getan haben und wie sehr es wehtun wird, etwas Neues in der Distribution zu aktualisieren oder zu installieren, da rc.local von external respektiert wurde Pakete, aber auf der anderen Seite, wenn ich einen Server installiere und eine systemd-Einheit oder zwei oder drei (oder sogar sysvinit-Dienste) erstelle, nur um eine einfache Aufgabe zu erledigen, kann dies manchmal Ihr Leben erschweren und viel mehr als dies meine Einheiten Namen können eines Tages zu Konflikten mit den Namen der neuen Dienste führen, die von der Distributionsentwicklung erstellt und möglicherweise bei einem Upgrade installiert wurden, was zu Problemen bei meinen Skripten führen kann!

Ich sehe eine andere Frage zu fragen , wo ist rc.local und die Antwort war , um es zu erstellen und Ausführungsberechtigungen zu geben, ich glaube , meine Frage ist wirklich nicht ein Duplikat , weil ich möchte nicht wissen , wo es ist - glauben Sie mir, ich will nur zu 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 schaffen?

Wie bereits an anderer Stelle erwähnt, wird es mäßig unrein, rc-local.serviceunter zu verwenden systemd.

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

rc-local.servicekann oft gut funktionieren. Wenn Sie sich darüber Sorgen machen, müssen Sie nur eine eigene Kopie davon 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 aktivieren systemctl enable my-startup.service.

2. Wenn Ihr Skript von einem anderen Dienst abhängig ist, einschließlich network-online.target, müssen Sie ihn deklarieren. ZB einen [Unit]Abschnitt hinzufügen , mit den Linien Wants=network-online.targetund After=network-online.target.

   Sie müssen sich keine Gedanken über Abhängigkeiten von "Early Boot" -Diensten machen - insbesondere von Diensten, die bereits zuvor bestellt wurden basic.target. Dienstleistungen wie my-startup.servicewerden automatisch nachbestellt basic.target, sofern sie nicht eingestellt sind DefaultDependencies=no.

   Wenn Sie nicht sicher sind, ob es sich bei einer Ihrer Abhängigkeiten um einen "Early Boot" -Dienst handelt, besteht ein Ansatz darin, die zuvor geordneten Dienste basic.targetdurch Ausführen aufzulisten systemctl list-dependencies --after basic.target. (Beachten Sie, das --afterist nicht --before).

Es gibt einige Überlegungen, die meiner Meinung nach auch für Pre-Systemd gelten rc.local:

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, keine lang laufenden Programme, auch bekannt als Daemons, zu starten rc.local.

[*] Ich habe Type=oneshot+ verwendet, RemainAfterExit=yesweil es für die meisten One-Shot-Skripte sinnvoller ist. Es wird formalisiert, dass Sie eine Reihe von Befehlen ausführen, die my-startupnach Abschluss als "aktiv" angezeigt werden und dass Sie keinen Dämon starten.

Vergiss es rc.local.

Wie gesagt zu CentOS 7 und zu Debian 8 und zu Ubuntu 15 :

Sie verwenden ein systemd + Linux-Betriebssystem. /etc/rc.localist ein doppelter Abwärtskompatibilitätsmechanismus in systemd, da es sich um einen Abwärtskompatibilitätsmechanismus für einen Mechanismus handelt, der selbst ein Kompatibilitätsmechanismus im rcKlon von van Smoorenburg System 5 war .

Die Verwendung /etc/rc.localkann schrecklich schief gehen. Die Leute waren überrascht über die Tatsache, dass systemd nicht rc.localganz auf die gleiche Weise läuft , an der gleichen Stelle im Bootstrap, wie sie es gewohnt sind. (Oder fälschlicherweise erwartet: Es lief nicht zuletzt auf dem alten System, wie das OpenBSD-Handbuch immer noch feststellt.) Andere waren überrascht, dass das, was sie bei der rc.localErwartung der alten Art und Weise, Dinge zu tun, eingerichtet haben, ist dann vollständig durch die Gleichen von neuen rückgängig gemacht udevRegeln, Networkmanager systemd-logind, systemd-resolvedoder verschiedene „Kit“ s.

Wie am Beispiel von „ Excess Argumenten‚auf Arch installieren? Warum `init 0 'in Folge‘ “, bereits einige Betriebssysteme systemd bieten , ohne die Abwärtskompatibilität verfügt wie der systemd-rc-local-generatorGenerator . Während Debian die Abwärtskompatibilitätsfunktionen beibehält , erstellt Arch Linux systemd mit deaktivierten Funktionen . Also auf Arch und Betriebssystemen wie es erwarten /etc/rc.local , völlig ignoriert zu werden .

Vergiss es rc.local. Es ist nicht der richtige Weg. Sie haben ein systemd + Linux-Betriebssystem. Stellen Sie also eine ordnungsgemäße System-Service-Einheit her und beginnen Sie nicht an einem Punkt, der zwei Ebenen der Abwärtskompatibilität entfernt ist. (Auf Ubuntu und Fedora, es ist drei mal entfernt, das van Smoorenburg System 5 - rcKlon, gefolgt rc.localdann gewesen sich zweimal überholt, vor über einem Jahrzehnt, die zuerst von Emporkömmling und dann von systemd.)

Denken Sie auch an die erste Regel für die Migration zu systemd .

Dies ist nicht einmal eine neue systemd-spezifische Idee. Auf van Smoorenburg- rcund Upstart-Systemen musste statt der Verwendung ein ordnungsgemäßes van Smoorenburg- rcSkript oder eine Upstart- Jobdatei erstellt werden rc.local. Sogar das Handbuch von FreeBSD stellt fest, dass man heutzutage ein richtiges Mewburn- rcSkript erstellt, anstatt es zu verwenden /etc/rc.local. Mewburn rcwurde 2000 von NetBSD 1.5 eingeführt.

/etc/rc.localstammt aus der Zeit von Seventh Edition Unix und früher. Es wurde von AT & T Unix System 3 (mit einem etwas anderen in AT & T Unix System 5) im Jahr 1983 abgelöst /etc/inittabund auf Runlevel-Basis . Auch das ist jetzt Geschichte.rc/etc/inittab

Erstellen Sie geeignete native Service-Definitionen für Ihr Service-Management-System, sei es ein Service-Bundle für das nosh-Toolset service-managerund system-controlein /etc/rc.d/Skript für Mewburn rc, eine Service-Unit-Datei für systemd, eine Job-Datei für Upstart oder ein Service-Verzeichnis für runit / s6 / daemontools -encore oder sogar ein /etc/init.d/Drehbuch für van Smoorenburg rc.

In systemd gehen solche vom Administrator hinzugefügten Service-Unit-Dateien /etc/systemd/system/normalerweise (oder /usr/local/lib/systemd/system/selten) ein. Mit dem nosh Service Manager /var/local/sv/ist ein herkömmlicher Ort für lokale Service-Bundles. Mewburn rcunter FreeBSD verwendet /usr/local/etc/rc.d/. Gepackte Service-Unit-Dateien und Service-Bundles, falls Sie sie erstellen, befinden sich jedoch an verschiedenen Orten.

Weitere Lektüre

• Lennart Pöttering et al. (2014). systemd-rc-local-generator . systemd manpages. Freedesktop.org.
• rc.local. FreeBSD System Manager-Handbuch . 2016-04-23.
• /unix//a/233581/5132
• Lennart Pöttering (29.08.2011). Bitte entfernen Sie /etc/rc.localoder chmod -xes . Redhat-Fehler # 734268.
• /unix//a/211927/5132
• Dirk Schmitt (19.12.2017). rc.localfängt zu früh an . Systemfehler # 7703
• https://wiki.archlinux.org/index.php?title=Systemd&diff=378926&oldid=378924
• Benjamin Cane (30.12.2011). Wann ist es in Ordnung und nicht in Ordnung zu verwendenrc.local . bencane.com.
• /unix//a/49636/5132
• Lennart Pöttering (01.10.2010). Wie konvertiere ich ein SysV-Init-Skript in eine systemd-Servicedatei? . 0pointer.de.
• /ubuntu/523369/
• Jonathan de Boyne Pollard (2015). /etc/inittabgehört der Vergangenheit an. . Häufig gestellte Fragen.
• Jonathan de Boyne Pollard (2014). Nebeneinander ausgeführte Skripte und Serviceeinheiten. . Häufig gestellte Fragen.
• Jonathan de Boyne Pollard (2014). Ein praktisches Beispiel für das Einrichten und Ausführen eines Dienstes mit nosh . Software.
• Jonathan de Boyne Pollard (2016). Msgstrsystemd.unit " Fehlende System - Suchpfade auf der Handbuchseite ". Errata für systemd doco . Häufig gestellte Fragen.

Zusammenfassung von https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Erstellen Sie /etc/systemd/system/rc-local.service:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

Dann:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

Erkundigen Sie sich bei:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service