Squeeze und folgende: Boot Prozess (Init)
Hallo allerseits,
auf mehrere Releases alten System wurde der Boot-Prozess umfassend
angepasst, d.h. es gibt angepasste Init-Skripten, eigene Init-Skripten,
die bislang keine LSB-Header tragen und einen massiv abgespeckten
Runlevel 2, verwaltet mit update-rc.d.
Mit Squeeze haben LSB-Header Einzug gehalten und es besteht die
Möglichkeit, den Boot-Prozess zu parallelisieren, was ich nicht
unbedingt brauche. Ferner habe ich den Eindruck gewonnen, dass die
klassischen Runlevel in kommenden Debian Releases durch "flexiblere"
Lösungen, wie systemd abgelöst werden könnten.
Aktuell habe ich in /etc/default/rcS CONCURRENCY=none gesetzt.
Ich möchte mir Gedanken dazu machen, die o.g. Anpassungen zukunftsfähig
zu machen.
Man findet viel Dokumentation zu den Neuerung, aber ich bin mir
unschlüssig, was überhaupt aktuell und zukunftssicher ist.
Unangenehm erscheint mir - vielleicht irre ich - dass man offenbar die
LSB-Header eines Init-Skripts anpassen muss, um die Runlevel und die
Startreihenfolge zu deklarieren. Mal abgesehen davon, dass man damit
widersprüchliche Angaben konfigurieren kann (LSB-Header: so, rc?.d/*:
anders), sehe ich es als extrem nachteilig an, ein Startskript anpassen
zu müssen, um etwa den Start in RL 2 durch einen Stop zu ersetzen. Das
führt nämlich dazu, dass das Init-Skript beim nächsten Paketupdate
manuell angepasst werden muss. Bei vielen betroffenen Skripten ist wäre
das arg umständlich. Aber vielleicht gibt es ja einen Trick...
Wohin geht die Reise denn nach aktuellem Stand der Planung und was wird
für die Übergangszeit empfohlen?
Viele Grüße
Michael
PS: Auf einem anderen Testsystem habe ich mich an einem eigenen
Init-Skript mit LSB-Headern versucht, welches es leider nicht tut. Es
"wirkt" wohl wie gewünscht, aber startpar meldet, dass das Skript
fehlschlug. Wenn ich das Skript auf der Konsole starte, kann ich kein
Problem feststellen. Gekürzt: http://paste.debian.net/134116/
--
EDV-Serviceteam Annika & Michael Hierweck GbR
Egerstraße 53, 44225 Dortmund (Germany)
http://www.edv-serviceteam.net
Reply to: