Start der camd in rcS / rcS.insmod

[saruman]

Lass uns mal hier weitermachen, das hat ja nicht direkt was mit Barfs newmale Branch zu tun.

Hm, okay, ist aber auch erstmal nicht schlimm wenn da eine camd2 läuft, oder?

Okay, schön ist das nicht, gebe ich zu. Stört aber auch erstmal nicht denke ich. Und für lcars überlege ich mir dann noch was.

Kommt darauf an, was du als "nicht schlimm" bezeichnest?
- Lcars startet halt nicht mehr
- Yadd startet keine camd2 (rcS vergessen)

Wieso sollte Lcars nicht mehr starten nur weil vorher irgendwo die nicht benötigte camd2 gestartet wird?

Jou, mit der rcS haste recht, habbich fix angepasst. Danke!

[racker]

Wieso sollte Lcars nicht mehr starten nur weil vorher irgendwo die nicht benötigte camd2 gestartet wird?

Lcars hat eine eigene cam eingebaut. =>konflikt

[saruman]

Ah, now I see the light. Okay, ich bau 'nen workaround bis ich mir was vernünftiges hab einfallen lassen.

[Tommy]

@saruman:

vieleicht doof die Frage, aber warum soll die camd nun aus der rcs gestartet werden? Welchen Vorteil hat das?

[saruman]

vieleicht doof die Frage, aber warum soll die camd nun aus der rcs gestartet werden? Welchen Vorteil hat das?

Nö, ist nicht doof.

Auf den ersten Blick hat das erstmal keinen Vorteil. Da Barf und ich in Barfs Thread aber mal überlegt haben, ob es nicht sowieso sinnvoll ist die Startscripte zu überarbeiten (wieso z.B. muss die camd in start_neutrino/start_enigma gestartet werden, da hat sie m.E. erstmal nix zu suchen weil sie mehr so GUI-unabhängig arbeitet) hatte ich damit angefangen. Okay, dass Lcars sich dabei auf die Klappe gelegt habe ich schlichtweg nicht gewusst - ich hab das ganz einfach noch nie benutzt und mangels Wartung weiß ich da auch nix drüber.

An sich strebe ich sowieso eine elegantere Art und Weise an, wie der ganze Kram auf den Boxen gestartet werden soll - mehr so Linux-konform. Mitte des letzten Jahres hatte ich damit auch schon mal angefangen, ist aber mangels Zeit liegengeblieben. Jetzt soll's endlich schön werden.

[Nico 77]

vieleicht doof die Frage, aber warum soll die camd nun aus der rcs gestartet werden? Welchen Vorteil hat das?

Nö, ist nicht doof.

Auf den ersten Blick hat das erstmal keinen Vorteil. Da Barf und ich in Barfs Thread aber mal überlegt haben, ob es nicht sowieso sinnvoll ist die Startscripte zu überarbeiten (wieso z.B. muss die camd in start_neutrino/start_enigma gestartet werden, da hat sie m.E. erstmal nix zu suchen weil sie mehr so GUI-unabhängig arbeitet)...

Ich finde diese Änderung ehrlich gesagt unpassend.

Aus der rcS wurden bisher immer die Treiber gestartet und in den jeweiligen Startscripten die jeweiligen camd's bzw deamon's.

Das ganze jetzt nun auch noch durcheinander zu werfen finde ich nicht ok.

Meine Meinung dazu.

[JtG-Riker]

vieleicht doof die Frage, aber warum soll die camd nun aus der rcs gestartet werden? Welchen Vorteil hat das?

Nö, ist nicht doof.

Auf den ersten Blick hat das erstmal keinen Vorteil. Da Barf und ich in Barfs Thread aber mal überlegt haben, ob es nicht sowieso sinnvoll ist die Startscripte zu überarbeiten (wieso z.B. muss die camd in start_neutrino/start_enigma gestartet werden, da hat sie m.E. erstmal nix zu suchen weil sie mehr so GUI-unabhängig arbeitet)...

Ich finde diese Änderung ehrlich gesagt unpassend.

Aus der rcS wurden bisher immer die Treiber gestartet und in den jeweiligen Startscripten die jeweiligen camd's bzw deamon's.

Das ganze jetzt nun auch noch durcheinander zu werfen finde ich nicht ok.

Meine Meinung dazu.

Seh ich genauso, da ich aber in meinem Image eh andere start-scripte hab ist es mir eigendlich egal *duck*

[saruman]

Hmmm, hab da heute Nacht auch noch mal in meinen schlaflosen Stunden drüber nachgedacht und als Ergebnis die Änderungen wieder zurückgenommen. Irgendwie war das noch nicht ausgereift was ich da fabriziert habe. Ich geh noch mal in mich.

[Tommy]

also vom Grunde her hast Du vermutl. Recht. In der start.neutrino sollte nur das gestartet werden, was neutrinospezifisch ist. Andererseits würde es nicht Sinn machen in einem rundumschlag eine start.daemons zu bauen? Damit könnte man die start.neutrino entschlacken und die rcs evtl. auch

[saruman]

Jo, so ähnlich schwebte es mir vor. Allerdings hatte ich die Nebenwirkungen (z.B. Lcars) nicht bedacht und die Sache mit der camd war nur ein erster Schritt - allerdings ein unausgegorener.

Andererseits wird ja bereits auf die Existenz der rcS.local gecheckt. An sich könnten Teile des Krams auch da rein (z.B. Start von tuxmaild, tuxcald, etc.).

Ich fänds auch klasse, wenn man Scripte zum Runterfahren der Box hätte (angefangen hatte ich letztes Jahr mal mit dem halt-Script, habs dann aber doch nicht mehr umgesetzt). Dort könnte man dann auch die GUI-unabhängigen Dienste wieder stoppen - und evtl. auch gleich eine halt.local (für die camd2 mit einbinden).

Irgendwie so, keine Ahnung. Sehr unrein gesprochen momentan.

[Barf]

Erstmals finde ich es super, wenn sich jemanden um die saubere Funktionalität kümmert, und nicht nur "noch ein geiles Feature". Das ein kleineres (ich meine es wirklich!) Missgeschick gelegentlich passiert; c'est la vie; kann mann rückgänglich machen. Einiges im Thread finde ich in Ton nicht richtig gelungen.

Die Organisation von /etc/init.d hat eine gewisse Verbesserungspotential. Hier ist es, während mehre "Generationen" von Entwickler, ein gewisse chaos gewachsen.

Ich halte nicht besonderes viel von "Meinungen", wichtiger ist es sich an Standards und etablierte Konventionen zu haltem, z.B. POSIX und Filesystem Hierarchy Standard.

Die "SysV"-orginisierung von /etc/init.d ist eine feine Sache. Jede "Systemkomponente" hat dann ein skript in /etc/init.d/, sowie diverse Links von runlevel directories /etc/init.d/rcN.d (N = 0,...m6), und wird dadurch bei systemstart (mehr korrekt, übergang zwischen verschiedene runlevels) gestartet (oder beendet). Das runlevelkonzept wäre nicht schlecht hier.

Ausserdem sollte mann es koppeln mit der Organisation der Makefiles. Beispiel: Ein neues "package" wie der automounter oder tuxcal. Jetzt wird dafür Files in .../cdk/root/etc/init.d eingefügt, Makefile.am in diesem Verzeichniss muss geändert werden, und in rcS[.insmod] muss das Ding gestartet werden (eventuell auch in (z.B) start_neutrino beendet!). Besser wäre, falls beim "make [flash-]automount" das Makefile bei automount entsprechende start/stop-skript in /etc/init.d installieren wurde, und keine Änderungen im .../etc/init.d (sowohl in CVS als auf der Box). Dies ist machbar: siehe "jede" moderne Linux/Unix.

Ich fänds auch klasse, wenn man Scripte zum Runterfahren der Box hätte

Im runlevelkonzept enthalten.

Andererseits wird ja bereits auf die Existenz der rcS.local gecheckt. An sich könnten Teile des Krams auch da rein

Die Meinung in FHS ist dass *.local im "Lieferzustand" leer sein soll.

[Houdini]

Dies ist machbar: siehe "jede" moderne Linux/Unix

Das ist richtig nur haben wir in der Box gerade mal 8 MB Speicher und nicht Gigabytes, das sollte man auf jeden Fall bedenken.
Und die Bootzeit wird durch N Startskripte auch nicht kürzer.

Houdini

[saruman]

Ich hatte auch mal darüber nachgedacht, auf der Box Init-Scripte zu etablieren. Das hätte u.A. auch den Vorteil man neben Start- und Stop-Optionen auch so nützliche Dinge wie restart oder auch reload (man denke z.B. an die neu zu ladenden Senderlisten) implementieren könnte. Ehrlich gesagt war das sogar mein Masterplan, den ich aber aufgrund der Komplexität recht schnell wieder verworfen hatte.

Aber ja, der verfügbar Speicher ist in der Tat ein Problem. Weil: Momentan werden Dienste einfach nur in den rcS* und start* Scripten gestartet und auch wieder beendet. Das sind für jeden Dienst max. 6 Zeilen (bei manchen wie z.B. zapit oder camd2 momentan noch weniger). Ein Init-Script würde da deutlich mehr an Platz beanspruchen.

Und: Um so Optionen wie z.B. reload zu verwirklichen müssten die Daemons auf Signals wie HUP und so hören - sprich: Hier wäre sicher erheblicher Aufwand vonnöten denke ich(den Aufwand können andere aber besser abschätzen als ich). Ich weiß nicht ob sich das jemand antun möchte.

[Bimmel]

was für reload ?

[saruman]

Bei manchen Daemons kann es sinnvoll sein einen HUP zu senden - z.B. der inetd muss keinen Restart bekommen nur weil man die inetd.conf verändert hat. Für neutrino selber könnte ich mir vorstellen, dass bei einem Reload die Senderlisten neu eingelesen werden (nur eine Idee, nicht gleich draufschlagen), etc. pp.

[Bimmel]

dass bei einem Reload die Senderlisten neu eingelesen werden

nein , senderlisten werden von zapit neu geladen , neutrino sendet nur ein befehl auf zapit.

[saruman]

Dann eben zapit und nicht neutrino. Ist doch auch zur Verdeutlichung der Funktionalität egal, oder?

[Barf]

Nicht alle init-skripts hat ein reload-Funktionalität: nur wo es ein Sinn hat. Umgekehrt: wo es Sinn hat, ist es sehr nett, diese Funktionalitär ein einheitliges auruf, z.B. /etc/init.d/dingsbums reload. Vgl der Automounter.

Neutrino und seine Daemonen sollte mann übrigens als Einheit betrachten: controld und sectionsd hat ohne Neutrino kein Sinn.

[Bimmel]

Neutrino und seine Daemonen sollte mann übrigens als Einheit betrachten: controld und sectionsd hat ohne Neutrino kein Sinn.

So ist es.