Hallo Liste! Zunächst sorry für das Doppelpost, ich hatte vergessen, die Signierung abzuschalten bzw hat damit offenbar etwas nicht funktioniert :-( Folgendes Problem: Irgendwann während der letzten Versionswechsel wurde das Bootkonzept von SuSE geändert/erweitert. Es geht dabei darum, dass Startskripte von unabhängigen (?!) Diensten parallelisiert wird. Gesteuert wird dies über die Konfiguration in den /etc/init.d/.depend.* Dateien, aus- und eingeschaltet über den Parameter "RUN_PARALLEL" in /etc/sysconfig/suseconfig. Mein Problem ist nun, dass Dienste, für die für den gewünschten Runlevel in /etc/rc.d/rc*.d ein korrekter SXXfoo Link für ein Startskript in /etc/rc.d erstellt wurde, unter Umständen gestartet wird, wenn kein Eintrag in /etc/rc.d/.depend.start erstellt wurde. Einen entsprechenden Eintrag dort zu erstellen ist grundsätzlich kein Problem, jedoch ist nicht ganz klar, wer dort noch Einträge erzeugt bzw wie es passieren kann, dass solche Einträge hin und wieder auf unerklärliche Weise wieder verschwindnen (YaST??). Der Runlevel-Editor kann es nicht alleine sein, denn den verwende ich ohnehin nicht. Konkret tritt bei mir das Problem zB im Zusammenhang mit einem Skript auf, das im Hintergrund läuft und meine DSL-Verbindung überwacht und diese ggf neu startet und dann sockd und xntpd neustartet. Die Sache ist auch die, dass das alles selbst ohne eigene Anpassungen der start/stop Skripte fehlerbehaftet ist, Beispiel: der xntpd ist von network und named abhängig, weil zunächst eine "initial time" geholt wird und erst dann der eigentliche xntpd gestartet wird. Ohne network startet der Dämon erst gar nicht richtig. Diese Abhängigkeit ist nicht korrekt in .depend.start verankert. Meine Fragen, nachdem ich nirgendwo entsprechende Information dazu gefunden habe, auch nicht in der SDB von SuSE: * Welcher Mechanismus ist für die Parallelisierung verantwortlich? * Wo wird festgelegt, welche Dienste von welchen anderen abhängig sind? * Wie kann ich erreichen, dass ein entsprechendes Startskript SXXfoo auf jeden Fall abgearbeitet wird, auch wenn kein Eintrag in der .depend.start erstellt wurde? * Wie kann ich erreichen, dass meine eigenen Einträge auf /etc/rc.d/.depend.start nicht verschwinden * Welche Nachteile - ausser einem langsameren Startprozess - hat das Abschalten dieses ominösen Parallelisierungsmechanismus? * Wo ist das ganze Ding dokumentiert? Vielleicht kann irgend jemand Licht in dieses Dunkel bringen - ich bedanke mich schon jetzt dafür ;-) Markus
Hallo, "Markus Heidinger" <suselist@mh-infoman.com> writes:
Hallo Liste! [...] Folgendes Problem: Irgendwann während der letzten Versionswechsel wurde das Bootkonzept von SuSE geändert/erweitert. Es geht dabei darum, dass Startskripte von unabhängigen (?!) Diensten parallelisiert wird. Gesteuert wird dies über die Konfiguration in den /etc/init.d/.depend.* Dateien, aus- und eingeschaltet über den Parameter "RUN_PARALLEL" in /etc/sysconfig/suseconfig. [...]
Meine Fragen, nachdem ich nirgendwo entsprechende Information dazu gefunden habe, auch nicht in der SDB von SuSE:
* Welcher Mechanismus ist für die Parallelisierung verantwortlich? * Wo wird festgelegt, welche Dienste von welchen anderen abhängig sind? * Wie kann ich erreichen, dass ein entsprechendes Startskript SXXfoo auf jeden Fall abgearbeitet wird, auch wenn kein Eintrag in der .depend.start erstellt wurde? * Wie kann ich erreichen, dass meine eigenen Einträge auf /etc/rc.d/.depend.start nicht verschwinden * Welche Nachteile - ausser einem langsameren Startprozess - hat das Abschalten dieses ominösen Parallelisierungsmechanismus? * Wo ist das ganze Ding dokumentiert?
Vielleicht kann irgend jemand Licht in dieses Dunkel bringen - ich bedanke mich schon jetzt dafür ;-)
Die Dateien .depend.boot, .depend.start, .depend.stop werden von insserv(8) angelegt. Die entsprechenden Abhängigkeiten werden in den scripten /etc/init.d/<script> definiert, alles was zwischen ### BEGIN INIT INFO und ### END INIT INFO steht, wird ausgewertet. Durch Veränderung der Required-start und Required-stop Parameter kannst du das Bootverhalten beeinflussen. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo, ich verwende einen SCSI-Host-Adapter des Typs SYM 21C002, der zwei Kanäle besitzt. Kanal A ist allerdings auf der Karte hinten angeordnet und hat somit auch den externen Anschluss. Kanal B ist Vorne und hat den 68-poligen Stecker. Daher habe ich (was möglich ist) die sog. Bootorder geändert, sodass der Kanal B der erste Kanal ist, Kanal A der Zweite. Soweit geht das ganz gut. Da ich auch einen Wechselrahmen verwende, der an Kanal A angeschlossen ist, ist diese Reihenfolge auch wichtig, denn da ist nicht immer eine Festplatte drin (manchmal auch ein Streamer). Dadurch ändert sich die Zahl der SDx-Devices an diesem Kanal. Und genau da liegt das Problem. Bis SuSE 8.x hat der Treiber diese BIOS-Reihenfolge problemlos unterstützt, das bedeutet, dass automatisch die erste Platte an Kanal B (die Bootplatte) das Device SDA war. Dadurch wurden die Platten am Kanal A entsprechend am Ende angeordnet und man musste nur beachten, dass (wegen eines externen SCSI-Gehäuses) die ID schön hoch war, dann wurde die Platte im Wechselrahmen automatisch die mit der höchsten Device-Bezeichnung (zum Beispiel SDE). Beim neuen Linux (keine Ahnung, wann das anders wurde) kann ich jedoch machen, was ich will, der Kanal A wird vom Kernel zuerst gescant. Dadurch ist das Alles jetzt ein bisschen durcheinander. Die Einträge in der fstab habe ich zunächst korrigiert, aber das ist natürlich keine Dauerlösung, da ich die Platte im Wechselrahmen nicht verwenden kann, dann verschieben sich alle Bezeichnungen des ja wichtigereren Kanal B entsprechend. An Kanal A sind, schon wegen der nur 50-poligen Verbindung, sonst nur andere Devices wie CD-ROM oder Brenner angeschlossen. Hat jemand eine Idee, wie ich dem Kernel die andere Reihenfolge beibringen kann? Ich werde dass nie anders verwenden, es muss also keine automatischer Mechanismus sein, selbst statische Veränderungen in den Kernel-Sourcen sind eine Variante. Ansonsten natürlich Boot- Parameter. Ich verwende Lilo (nicht Grub), da ich bei dem besser mit dem Setup des Bootloaders zurechtkomme, die Parameter von Grub kapiere ich irgendwie nicht. Tschüß Manfred Preussig
participants (3)
-
Dieter Kluenter
-
Manfred Preußig
-
Markus Heidinger