[P3f]

Hi Claus,

ich habe nun -nach deiner Anpassung im Makefile.tools- einen kompletten Build neu bauen lassen. Sieht sehr gut aus, einzig bei dem dvb-remote habe ich noch "merkwürdige Meldungen" (oder kann man die ignorieren?)

ignored deprecated option -m
WARNING: could not open /home/pit/MLD/dvb-remote/./lib/modules/3.8.4.165/modules.order: No such file or directory
WARNING: could not open /home/pit/MLD/dvb-remote/./lib/modules/3.8.4.165/modules.builtin: No such file or directory

Gruß,

Pit

[clausmuus]

Die resultierenden pci und usb map files unterscheiden sich im Aufbau.
Um's richtig zu machen, hätte ich ganz auf die map files verzischen sollen und auf der mld direct die Alias Datei auslesen, aber da ist die Wahrscheinlichkeit das mir nen Fehler unterläuft noch größer. So habe ich erst einmal den weg des geringsten Risikos gewählt.

Claus

[wino]

Glaube nicht das es etwas, außer einer kosmetischen Korrektur in der rc.init bringt.

Code: [Select]

echo "$name seems to hang or takes longer to start! continue now..."Wenn die vorgegebene Startreihenfolge, die in den Inits der Addons und Plugins steht, nicht eingehalten werden kann, bringt es das System durcheinander. Nutzt ja nichts wenn das Netzwerk irgendwann startet, sondern nur zum richtigen Zeitpunkt. Von dessen rechtzeitigen Start hängen wieder andere Addons ab. Gleiches trifft auch auf Abhängigkeiten bei anderen Addons zu. Als es noch kein Dbus, Avahi, Avahi-linker, Udevil, irerver usw. in MLD gab, war die Einhaltung der Startreihenfolge kein großes Problem.

[Christian]

Glaube nicht das es etwas, außer einer kosmetischen Korrektur in der rc.init bringt.

Code: [Select]

echo "$name seems to hang or takes longer to start! continue now..."Wenn die vorgegebene Startreihenfolge, die in den Inits der Addons und Plugins steht, nicht eingehalten werden kann, bringt es das System durcheinander. Nutzt ja nichts wenn das Netzwerk irgendwann startet, sondern nur zum richtigen Zeitpunkt. Von dessen rechtzeitigen Start hängen wieder andere Addons ab. Gleiches trifft auch auf Abhängigkeiten bei anderen Addons zu. Als es noch kein Dbus, Avahi, Avahi-linker, Udevil, irerver usw. in MLD gab, war die Einhaltung der Startreihenfolge kein großes Problem.

[clausmuus]

Hi,

feine Idee, aber die MLD verwendet bereits nen System das genau wie systemd arbeitet, nur halt schon ein wenig älter ist.
Das Fortsätzen des Bootvorganges im Fehlerfall ist auch wichtig, da ansonsten ein suchen der Fehlerursache nicht möglich wäre. Ne Konsole gibt's halt erst nach abgeschlossenem Boot Vorgang.
Nichts desto trotz habe ich selber bereits da drüber nachgedacht mir mal das systemd genauer anzuschuen. Schließlich kann das inzwischen noch ein wenig mehr, als Startscripte in der optimalen Reihenfolge zu starten. Nur ob wir irgendwas davon wirklich brauchen weiß ich nicht. Und ob der zusätzliche Ballast nun mehr hilft oder bremst würde sich erst nach nem Test zeigen.

Claus

[Christian]

Ich denke es würde nicht Schaden wenn du kurz niederschreiben würdest wie genau sich die einzelnen Variablen verhalten.

After=
Before=
Priority=

Wann muss wie was eingesetzt werden?

After befor sollte klar sein , denke ich
Priority=9 ist so früh wie möglich, wobei <9 dann immer weniger Priorität erhält (Nachteil das Script stoppt auch so früh wie möglich) hier müsste dann mit zwei init scripten für Start und stop gearbeitet werden.

Es wäre gut wenn du (Claus ) noch ein Satz dazu schreiben würdest  

[clausmuus]

Hi,

Deine Zusammenfassung der Bedeutung ist genau richtig. Nur bedeutet ne hohe Priorität nicht auch nen frühes stoppen, sondern nen spätest stoppen. => Je größer die Priorität, desto früher starten und später stoppen.
Ne Priorität wird nur dann gesetzt, wenn was besonders frü gestartet werden soll, also z.B. für den VDR (am höchsten) und den xserver (auch hoch). Alles was vor dem VDR gestartet werden muss, wird auch vorher gestartet, auch wenn dafür keine oder eine niedrige Priorität angegeben ist. Halt genau wie bei systemd. Nur das dort die Parameter in getrennten Dateien stehen.

Claus

[wino]

Hallo,

Nichts desto trotz habe ich selber bereits da drüber nachgedacht mir mal das systemd genauer anzuschuen. Schließlich kann das inzwischen noch ein wenig mehr, als Startscripte in der optimalen Reihenfolge zu starten. Nur ob wir irgendwas davon wirklich brauchen weiß ich nicht. Und ob der zusätzliche Ballast nun mehr hilft oder bremst würde sich erst nach nem Test zeigen.

Claus

Da beispielsweise OpenELEC und Openbricks auch auf systemd aufbauen, kann ich mir schlecht vorstellen dass dort unnötiger Ballast mitgeschleppt wird.  

Sollte mit der bisherigen Lösung eine verlässliche Startreihenfolge realisierbar sein, ist es mir auch recht. Nur greift dieser Mechanismus derzeit nicht ausreichend oder ich mache etwas falsch.

Es soll zum Beispiel das Netzwerk vor VDR, D-Bus und Avahi bereit sein. Zweite Bedingung. Irserver soll nach eventlircd aber vor irserver2uinput starten. Eventlircd vor VDR.  D-Bus vor avahi und avahi-linker nach avahi. Die Eintragungen mit after= und before= in den jeweiligen Skripten helfen da nicht immer. Weshalb bei dem Startskript udevil eine Startverzögerung mit der bekannten Meldung kommt ist mir schleierhaft.

Du könntest dir die init Skripte mal ansehen und mögliche Fehler korrigieren.

Gruß wino  

[clausmuus]

Hi,

das MLD System arbeitet zuverlässig. Lediglich wenn die besagte Meldung kommt, wird die jeweilige Regel übersprungen. Das rührt aber in jedem Fall von nem Fehler in dem entsprechenden Init Script her, bzw. das Init Script braucht einfach zu lange. In beiden fällen muss das betreffende Init Script korrigiert werden, denn mehr als 60 Sekunden sollte nen korrektes Init Script nun wirklich nicht brauchen.
Wie gesagt, das MLD System macht genau das selbe wie systemd. Ich weiß ja nicht wie groß das systemd Paket ist, die MDL Variante benötigt jedenfalls lediglich 2,8Kb und ist sehr schnell da sie kaum Overhed hat.

Claus

[wino]

Wenn alles so bleiben soll wie es im Moment ist und alles bestens funktioniert, ist es mir auch recht. Habe keine Lust wieder wochenlange

[P3f]

Hi,

ich will mich nicht zu den wissenden zählen, aber ja die Startreihenfolge arbeitet (für eine Laienbetrachtung) gut und stabil. Nur ist es halt wirklich immer wieder schwierig diesen ganzen Abhängigkeitswirrwar nach zu vollziehen. Und Claus, meinst Du mit den 60 Sekunden, den "wait-60" in den /etc/init.rc.init vom INITRAMFS-Addon? Dort ist doch auf 10 Sekunden vermindert worden. Ich habe es eingetragen, da es für die MLD 3.0.2 unter PRECISE-Branch so gemacht worden ist und ich den RARING-Branch doch "gerade" gezogen hatte.

Also, wenn das falsch ist, dann darfst auf mich hauen....

Aber bzgl. dem systemd-Dienst noch einmal. Ich denke das der Dienst nicht überfrachtet worden ist, er bietet als einheitlichere Startreihenfolgemöglichkeiten (wenn ich es richtig verstanden habe). Und sicherlich ist da wieder an bestimmt einigen Stellen etwas anzupassen, wenn wir dadurch aber auch für weitere Startabhängigkeiten gewappnet sind dann sollten wir das angehen.

Ich weiß ich kann es nicht angehen, da ich kein Spezialist wie ihr es seit bin. Aber wenn jemand gebraucht wird, dann bin ich gerne zur Massenumsetzung /-unterstützung da. Nur brauche ich eine Anleitung....

So, ich will nie wieder auf die MLD verzichten. Das Konzept und die bisherige Umsetzung ist einfach und funktioniert so gut. Da kann ich schon verstehen, das man nichts ändern will. Rein nach dem Motto: Never change an running system. Aber udev-Veränderung ist ja auch sehr positiv geworden, auch wenn hier noch die Fernbedienung nicht im Webif sauber implementiert ist.
Also, ich hoffe das ihr Euch entscheidet ob man das Thema angehen muß.

Gruß,

Pit

P.S: Hoffe nun das keiner Beleidigt ist.

[clausmuus]

Hi,

ich hab nichts gegen ne Untersuchung und nen Test von systemd, nur denke ich das wir uns das sparen können. Wir haben halt bereits nen System das genauso arbeitet, und das dazu auch noch zuverlässig. Mir fallen auch keine zusätzlichen Möglichkeiten von systemd ein, die wir brauchen könnten. Wie gesagt, die Startreihenfolge wird dort genau wie bei unserem System festgelegt.

@P3f,

ja, ich meine die "wait-60". Und der Wert sollte auch nicht verkleinert werden, da es sich dabei nur um nen Notausstieg handelt, der bei nem Fehlerfreien System nicht ansprechen darf. Sollte irgend ein User, aus welchem Grund auch immer, nen anderen Wert brauchen, kann der in Bootmanager eingetragen werden.

Claus

[P3f]

Hi,

ich hab nichts gegen ne Untersuchung und nen Test von systemd, nur denke ich das wir uns das sparen können. Wir haben halt bereits nen System das genauso arbeitet, und das dazu auch noch zuverlässig. Mir fallen auch keine zusätzlichen Möglichkeiten von systemd ein, die wir brauchen könnten. Wie gesagt, die Startreihenfolge wird dort genau wie bei unserem System festgelegt.

@P3f,

ja, ich meine die "wait-60". Und der Wert sollte auch nicht verkleinert werden, da es sich dabei nur um nen Notausstieg handelt, der bei nem Fehlerfreien System nicht ansprechen darf. Sollte irgend ein User, aus welchem Grund auch immer, nen anderen Wert brauchen, kann der in Bootmanager eingetragen werden.

Claus

Hi,

ich habe nun wieder in dem INITRAMFS den Wert von Wait-60 (Sekunden) im rc.init-Script eingetragen, damit es wieder konform geht.

Gruß,

PIt

[Christian]

Hi,

ich hab nichts gegen ne Untersuchung und nen Test von systemd, nur denke ich das wir uns das sparen können. Wir haben halt bereits nen System das genauso arbeitet, und das dazu auch noch zuverlässig. Mir fallen auch keine zusätzlichen Möglichkeiten von systemd ein, die wir brauchen könnten. Wie gesagt, die Startreihenfolge wird dort genau wie bei unserem System festgelegt.

@P3f,

ja, ich meine die "wait-60". Und der Wert sollte auch nicht verkleinert werden, da es sich dabei nur um nen Notausstieg handelt, der bei nem Fehlerfreien System nicht ansprechen darf. Sollte irgend ein User, aus welchem Grund auch immer, nen anderen Wert brauchen, kann der in Bootmanager eingetragen werden.

Claus

Hi,

ich habe nun wieder in dem INITRAMFS den Wert von Wait-60 (Sekunden) im rc.init-Script eingetragen, damit es wieder konform geht.

Gruß,

PIt

Hab's bei dem jetzigen Build noch mit reinmassiert

[clausmuus]

Hi wino,

ich hab grad mal nen Blick in das udevil init Script geworfen. Da verwendest Du das start-stop-daemon tool um den Dienst zu starten. Wenn dieses Startscript also wirklich nicht sofort zurück kommt, so tippe ich da drauf, das dieses Tool nicht korrekt arbeitet. Eventuell reicht es ja schon, wenn auch die Standard Eingabe gekappt wird, also am Ende noch nen "</dev/null" angehängt wird? Vielleicht lohnt ja auch mal nen Blick in die Ausgaben des start-stop-daemon tools.

Claus