Wie wäre es denn (solange Freetz-NG seine Dienste nicht ordentlich in jeweils eigene Service-Files zerlegt, die Abhängigkeiten entsprechend beschreibt und generell den
supervisor zum Starten der Dienste, die sich aus Zusatzpaketen ergeben, nutzt - was ja die beste Lösung wäre), wenn beim Starten des
dnsmasq der
multid angehalten und im Anschluß neu gestartet wird?
Die Auswirkungen auf den
multid, wenn der (DNS-)Port bereits in Benutzung ist, habe ich hier irgendwo mal gezeigt (Stichworte
aicmd und
multid sollten zum erwähnten Beitrag führen) und solange man kein "Gespann" aus
multid und
dnsmasq für die Auflösung betreiben will (was ja ohnehin nur mit Kopfständen gelingen würde), schaltet der
multid dann eben lediglich die DNS-Funktionen ab und gut ist's.
Vermutlich ist das auch der Gedanke hinter dem zweiten Punkt in #2 ... nach meiner Erfahrung würde das so auch funktionieren, wobei man das Stoppen des
multid wohl am besten über den Parameter
-s macht, denn das (originale) Service-File enthält keinen
ExecStop-Eintrag (obwohl auch
ExecStop und sogar
ExecStopPost wohl implementiert sind) und beim Starten dann aber wieder auf
svctl zurückgreift, denn nur so erhält dann auch der supervisor wieder Kenntnis davon, daß der
multid.service wieder läuft und er ihn mit der neuen PID in seine Liste der Abhängigkeiten zwischen den Services einbauen kann.
Das ganze Geraffel in
rc.multid ist "Freetz-spezifisch" ... bei AVM gibt/gab es da gar kein eigenes
rc-File, das war alles in
rc.net enthalten.
Am einfachsten sind zwei zusätzliche Zeilen in der
rc.dnsmasq in den Funktionen
start (zum Anhalten des
multid) und
startdaemon_post (
https://github.com/Freetz-NG/freetz.../dnsmasq/files/root/etc/init.d/rc.dnsmasq#L25 - zum erneuten Starten des
multid), wobei man den ganzen Kram mit dem Ändern des Verhaltens des
multid (inkl. Wrapper) besser gleich ganz wegläßt als Patch.
Erst wenn man das alles noch mit Abfragen spicken will, ob das auch die richtige FRITZ!OS-Version und die passende Freetz-NG-Konfiguration ist, wird das aufwändiger und braucht mehr als die erwähnten zwei Änderungen in dieser einen Datei.
Allerdings wäre es natürlich auch denkbar, den Start des
dnsmasq selbst wieder über eine Service-Datei zu organisieren ... dann ist es noch viel einfacher dafür zu sorgen, daß der
multid erst NACH dem
dnsmasq gestartet wird ... nur paßt das dann - je nach Situation - nicht mehr zur sehr späten Initialisierung von Freetz-NG als "mod"-Paket und erst recht nicht dazu, wenn die Initialisierung von
external-Paketen erst "ganz weit hinten" im Ablauf erfolgt und man den
dnsmasq möglichst auch noch ausgelagert hat.
Die einzige, wirklich "saubere" Lösung wäre es hier sicherlich, den Start der ganzen Freetz-NG-Pakete ebenfalls auf die Möglichkeiten des parallelen Starts der Dienste umzustellen, was ja dank des
supervisor mittlerweile möglich ist - da lassen sich sogar die Starts von Freetz-NG-Paketen und von AVM-Daemons so weit miteinander verzahnen, daß einiges an Kopfständen vermeidbar ist, wozu einen zuvor der sehr späte Start von Freetz-NG (und das dann auch noch alles "seriell" und schön der Reihe nach) gezwungen hat.
Mit dem
supervisor ist es aber eben gar nicht mehr erforderlich, daß ein einmal gestarteter Service sich auch so schnell wie möglich initialisiert und danach die Steuerung wieder zurückgibt, damit der Startvorgang weitergehen kann ... da das alles parallelisiert ist, kann so ein Service (zum Beispiel für einen NTP-Client) auch einfach so lange warten, bis dann mal eine DSL-Synchronisation stattgefunden hat und die Uhrzeit irgendwie gesetzt wurde. Das behindert keinen einzigen anderen Service ... es sei denn, der wäre AUCH auf eine korrekt gesetzte Uhrzeit angewiesen und daher in seinem Service-File mittels
After=<any_service> als abhängig von einem vorher zu startenden Service markiert.
Man braucht also einfach nur ein passendes Service-File erstellen und das in
/lib/systemd/system werfen ... den Rest der ganzen Starterei übernimmt dann der
supervisor und wenn man sich nicht anders zu helfen weiß (AVM macht das auch so, daß von Version zu Version immer mehr Dienste auf dieses Startprinzip umgestellt werden), dann führt man eben bei Service-Start einfach das (alte)
rc-File aus.
AVM hat mittlerweile auch das WLAN vom LAN getrennt und startet das WLAN als gesonderten Service (
wifi.service) NACHDEM der Rest des Netzwerks bereits gestartet wurde (
After=network.target). Mit einiger Wahrscheinlichkeit hängt auch ein Problem mit "unvollständiger Bindung" des
dnsmasq an ein Interface bzw. das Fehlen des WLANs in der LAN-Bridge (falls das so sein sollte) mit dieser geänderten Reihenfolge zusammen ... ich kann derzeit nicht mal sicher sagen, WANN denn nun die Freetz-NG-Initialisierung beginnt (die dann ihrerseits ja erst wieder den
dnsmasq startet), denn ein Service, von dessen Initialisierung der Freetz-NG-Start abhängig ist (
https://github.com/Freetz-NG/freetz...5/patches/scripts/115-systemd-services.sh#L21) existiert in dieser Form in FRITZ!OS 07.50 gar nicht mehr (es gibt schlicht keinen
net.service mehr) und ob das jetzt am Ende heißt, daß der
supervisor diese Abhängigkeit dann ignoriert und die Freetz-NG-Initialisierung zu früh startet (nämlich bevor noch das Netzwerk initialisiert wurde) oder sie wieder GANZ ANS ENDE verschiebt, kann man nur raten (solange man die Implementierung dieses offensichtlichen
systemd-Abkömmlings nicht kennt) oder man muß es eben Schritt für Schritt ausprobieren (und dazu aber auch erst einmal ein Freetz-NG auf einem Gerät haben).
