[Eisfair] eisfair mit Systemd

[Alexander Dahl]

Hallo Marcus,

Marcus Röckrath schrieb Mittwoch,  8. März 2023, 20:05 (CET):
> Hallo Jürgen,
>
> Jürgen Witt wrote:
>
>>>>> Nun wird es Zeit auch eisfair mit Systemd auszuruesten.
>>>>
>>>> kann es sein, daß durch diese Änderung meine /etc/init.d/local
>>>> verschwunden ist?
>>>>
>>>> Dort hatte ich einen mount-Befehl hinterlegt, der jetzt natürlich nicht
>>>> mehr ausgeführt wird, was zur Folge hat, daß mein Backup auf allen
>>>> Servern nicht mehr funktioniert.
>>>> Was ist zu tun?
>>> 
>>> nein die ist im Prinzip nicht wech, die wurde umbenannt
>>> 
>>> /etc/init.d/boot.local
>> 
>> Aber mein Mount-Befehl wurde nicht ausgeführt. Habe ihn gerade an der
>> Konsole ausgeführt und nun steht in dem vorher leeren Verzeichnis
>> /backup auch wieder Inhalt.
>
> Die Analyse hat ergeben:
>
> Das Netzwerk ist noch nicht bereit, wenn boot.local ausgeführt wird, so dass
> Befehle, die auf das Netzwerk angewiesen sind, fehlschlagen - bei mir
> arpwatch, bei dir mount.
>
> Das liegt auch daran, dass die Umstellung auf systemd ein Work in Progress
> ist und noch nicht komplett durchgezogen ist.
>
> Es wird zwar die Netzwerkkarte initialisiert, aber dann schon boot.local
> gestartet, bevor danach erst die IP-Zuweisung zur Netzwerkkarte erfolgt,
> weil diese Zuweisung derzeit auch noch nicht über systemd erfolgt.
>
> Temporäre Lösung:
>
> Im Startzweig von /etc/init.d/boot.local eine kurze Pause einbauen:
>
> start)
>         sleep 20
>         <weitere Befehle>
>

Gibt es denn ein unit file für boot.local?  Das Skript selbst ist ja
individuell, da kennt quasi nur der Nutzer die Abhängigkeiten.  Also bei
Euch beispielsweise zu "Netzwerk komplett da" oder zu "Filesystem
einsatzbereit" oder whatever.  Mit dem Wissen könnte man ja die
entsprechenden Abhängigkeiten an der richtigen Stelle ergänzen, so dass
systemd das Ding erst startet, wenn alle Voraussetzungen gegeben sind.

Das Problem erinnert mich an eine Debian-Kiste, wo nach individueller
Änderung der Konfiguration mosquitto nicht mehr automatisch beim Boot
startete, weil der nun komplett fertiges Netzwerk brauchte.  In der
Shell History hab ich da so lustige Befehle wie bspw.

    systemctl list-dependencies mosquitto.service
    systemctl status mosquitto.service
    systemctl is-enabled systemd-networkd-wait-online.service
    systemctl edit mosquitto.service

Der letzte war hier entscheidend.  Damit öffnet systemd in einem Editor
die Datei '/etc/systemd/system/mosquitto.service.d/override.conf' und da
kann ich Ergänzungen zur mitgelieferten Unit machen.  Mit anderen
Worten: systemd baut dann die effektive Unit aus der eigentlichen Unit,
die irgendwo in '/usr' liegt und der override Datei irgendwo in '/etc'
zusammen.  Was ich dann in der override ergänzt hab, waren im Abschnitt
'[Unit]' die richtigen Services hinter "After" und "Requires":

    [Unit]
    After=networking.service
    Requires=networking.service

Wie die nötigen Services auf Euren Kisten heißen und ob das überhaupt so
bei eisfair funktioniert, kann ich natürlich nicht sagen.  Insbesondere
weil boot.local ja ein automatisch konfigurierter SysV Service ist.
Kein Ahnung ob man da eine override ergänzen kann.

Aber so mal als Anregung: anstatt timeouts als Workarounds einzubauen
besser die Werkzeuge nehmen, die systemd mitbringt.  Dafür muss man dann
mal ins Handbuch gucken.  Ich empfehle für den Anfang systemctl(1) und
systemd.unit(5) und dort insbesondere die Abschnitte zu Before=, After=,
Requires= und Wants= ;-)

HTH & Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6