Reihenfolge der Initscripte

[pil]

Wie es aussieht ist die alte Festlegung der Reihenfolge der Ausführung der Initscripte in /etc/rcS.d etc. mit

S01erstes_script -> ../init.d/erstes_script
...
S99letztes_script -> ../init.d/letztes_script

reine Makulatur.

Wie es aussieht kann man die Reihenfolge gar nicht mehr genau festlegen.
Ich habe jetzt durch eine Änderung des Headers in bootlogd

# Required-Stop: rc.local

zumindest erreicht, dass rc.local wenigstens noch ausgeführt wird bevor der Bootlogger gestoppt wird. Das Ergebnis ist, dass es zwar davor ausgeführt wird, dafür wird es - wie noch andere Initscripte auch - beim Booten zwei Mal ausgeführt.

Weiss jemand, wo man dazu (speziell zur Reihenfolge der Ausführung der Initscripte und wie und wo das alles festgelegt wird und wie und wo man am besten eingreift, wenn man selber etwas festlegen will) eine ordentliche Dokumentation findet?

Und, da das alles ja nicht mehr über drei, vier Ecken läuft, sondern bereits über fünf, sechs Ecken: Ist es möglich, upstart durch systemd zu ersetzen?

[pil]

Ok, gerade gesehen: 'Wheezy' verwendet kein upstart, sondern das alte - stark modifizierte - sysvinit.

Der Einwand (und die Frage) bleibt bestehen: Das - stark modifizierte - sysvinit läuft bereits über fünf, sechs Ecken. Ich hätte es deshalb gerne los. Kann man es durch systemd ersetzen?

[pil]

Beste Dokumentation (mit Links zu weiteren Dokus), die ich bisher dazu gefunden habe:

http://wiki.debian.org/LSBInitScripts/

Mit dem 'facility' $all sollte man einstellen können, dass ein Script beim Booten zuletzt ausgeführt wird. Aber man kann damit auch Überraschungen erleben, wie es so schön heisst, "It is not possible to depend on a script which depend on $all."

Irgendwie scheint der Hauptzweck von "dependency based boot" darin zu liegen, das ganze komplexer und undurchblickbarer zu machen. Schneller als der alte "statische" Bootvorgang ist es - trotz Parallelisierung - jedenfalls nicht.

Man könnte es auch so ausdrücken: Die Zeit, die grub - etwa im Vergleich zu lilo - benötigt, kann auch der schnellste Bootvorgang nicht mehr wettmachen.

[rendegast]

Man könnte es auch so ausdrücken: Die Zeit, die grub - etwa im Vergleich zu lilo - benötigt, kann auch der schnellste Bootvorgang nicht mehr wettmachen.

Das ist nicht richtig.
Wenn Du GRUB_TIMEOUT entsprechend wählst, startet grub sofort den kernel.

Irgendwie scheint der Hauptzweck von "dependency based boot" darin zu liegen, das ganze komplexer und undurchblickbarer zu machen.

Es ist einfach "anders",
wenn Du daran herumsortieren willst, so lege Kopien der header nach /etc/insserv/overrides/ und arbeite damit.
Vergiß bei Problemen aber dann nicht eventuell dort liegende Ostereier.

Ich habe jetzt durch eine Änderung des Headers in bootlogd

# Required-Stop: rc.local

zumindest erreicht, dass rc.local wenigstens noch ausgeführt wird bevor der Bootlogger gestoppt wird. Das Ergebnis ist, dass es zwar davor ausgeführt wird, dafür wird es - wie noch andere Initscripte auch - beim Booten zwei Mal ausgeführt.

? Was hattest Du da vor und was hast Du dafür angestellt?
/etc/init.d/rc.local / /etc/rc.local wird im Default am Ende der Multiuser-Level ausgeführt, fertig.

Code: Alles auswählen

# ls -1 /etc/rc5.d/
....
S04gdm
S05bootlogs
S06rc.local
S06rmnologin
S06stop-bootlogd

ohne jede Änderung.

Wenn das so aussehen soll:

Code: Alles auswählen

# ls -1 /etc/rc5.d/
....
S04gdm
S05bootlogs
S06rc.local
S07rmnologin
S07stop-bootlogd

Dann eine (header-)Kopie von rc.local nach /etc/insserv/overrides/ und darin

Code: Alles auswählen

...
# Required-Start:    $remote_fs $syslog bootlogs
...

Dann 'insserv -v'.
Jedoch ist damit noch nicht gesichert, daß die Meldungen der rc.local-Befehle in /var/log/boot landen.




-------------------------------------------------------------
Hier hast Du noch ein einfaches /etc/init.d/rc.boot,
ausgeführt am Ende des Start-Levels werden Skripte in /etc/rc.boot/ abgearbeitet:

Code: Alles auswählen

#! /bin/sh
### BEGIN INIT INFO
# Provides:          rc.boot
# Required-Start:    $all
# Required-Stop:
# Default-Start:     S
# Default-Stop:
# Short-Description: Run /etc/rc.boot.d/ if it exist, SELBSTANGEFERTIGT - nach Template rc.local
### END INIT INFO
######## Required-Start:    $remote_fs $syslog $all


PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_start() {
	if [ -d /etc/rc.boot.d ]; then
	        [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (in /etc/rc.boot.d/)"
		run-parts /etc/rc.boot.d
		ES=$?
		[ "$VERBOSE" != no ] && log_end_msg $ES
		return $ES
	fi
}

case "$1" in
    start)
	do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

[pil]

Ich weiss, dass /etc/init.d/rc.local nur /etc/rc.local aufruft.
Letzteres ist sozusagen mein eigenes rc.local.

Meine eigentliche Absicht war, rc.local auszuführen bevor der Bootlogger gestoppt wird, damit die message von rc.local in /var/log/boot erscheint.

Aber bereits dieses Ansinnen führte zu (fast) unüberwindlichzen Problemen.
Der Grund dafür war vermutlich, dass sowohl /etc/init.d/rc.local als auch /etc/init.d/stop-bootlogd-single (also jenes Script, welches bootlogd stoppt)

im Header jeweils den gleichen Eintrag aufwiesen:

# Required-Start: $all

Und das geht ja nun logischerweise nicht.

rc.boot habe ich glücklicherweise nicht. "Glücklicherweise" deshalb, weil es das dritte Script wäre, das zuletzt ausgeführt werden will.

Man bräuchte ein $all -1, $all -2 etc. Womit wir - über den Umweg der sechsten Ecke - wieder bei der ursprünglichen flexiblen Einstellungsmöglichkeit angelangt wären.

[pil]

Das zweimalige Ausführen ist scheinbar ein anderes Problem. Hier ein Ausschnitt aus /var/log/boot, wie es von Anfang an bei 'Wheezy' eingerichtet wurde:

Code: Alles auswählen

Wed Jul 18 04:48:30 2012: Mounting local filesystems...done.
Wed Jul 18 06:48:30 2012: Activating swapfile swap...done.
Wed Jul 18 06:48:31 2012: [ ok ] Cleaning up temporary files....
Wed Jul 18 06:48:31 2012: [ ok ] Configuring network interfaces...done.
Wed Jul 18 06:48:31 2012: [ ok ] Cleaning up temporary files....

Ebenso wird rc.local zwei Mal nicht unmittelbat hintereinander aufgerufen, - aber nicht am Schluß. Inzwischen bin ja schon froh, dass es *überhaupt* aufgerufen wird und auch in /var/log/boot erscheint.

[rendegast]

Aber bereits dieses Ansinnen führte zu (fast) unüberwindlichzen Problemen.

Bei mir war es nur obiger fix,
ist halt eine Sache der Erfahrung.

rc.boot habe ich glücklicherweise nicht.

Natürlich nicht, steht ja auch im Header, "SELBSTANGEFERTIGT".
Eine Idee nach suse oder einer früheren debian-Version.

Ebenso wird rc.local zwei Mal nicht unmittelbat hintereinander aufgerufen,

Da werden (Sicherungs?)Kopien der Skripte abgearbeitet?

Code: Alles auswählen

ls -1 /etc/rc*.d/

Eine doppelte Ausgabe durch zwei gestartete bootlogger erzeugt?

[pil]

Eine doppelte Ausgabe durch zwei gestartete bootlogger erzeugt?

Sorry, das verstehe ich nicht. Wie kann so etwas passieren?
Und wie kann ich verhindern, dass es passiert?

Auch mit deinem Fix kriege ich es nicht hin, dass

1. rc.local immer als vorletztes Script gestartet wird,

2. rc.local nur ein Mal ausgeführt wird.

[rendegast]

Wie kann so etwas passieren?

Indem ich am Startsystem herumkonfiguriere.

Code: Alles auswählen

insserv -v

ls -1 /etc/rc*.d/

Code: Alles auswählen

ls -l /etc/insserv/overrides/

cat /etc/insserv/overrides/*

ZBsp. die Pakete von oracle-virtualbox haben notorisch kaputte Startskripte,
und bringen insserv durcheinander.

[pil]

Durch die Erläuterungen in /usr/share/doc/sysv-rc/README.runlevels.gz
habe ich es - wie es aussieht - hingebracht.

Die Header der von mir erwähnten Initscripts sind unverändert.

Im Verzeichnis /etc/rcS.d darf kein Link auf /etc/init.d/rc.local vorhanden sein, sonst wird es hier und in /etc/rc2.d nochmals ausgeführt.

[rendegast]

Den Link hast Du aber auch selbst dort erstellt, 'ls -1 /etc/rc*.d/' hätte das gezeigt.
Nimmst Du jetzt die Schmäh übers init-System zurück?

[pil]

Nimmst Du jetzt die Schmäh übers init-System zurück?

Tut mir ehrlich leid, aber ich kann das nicht zurücknehmen.

Das Zeug ist einfach viel zu komplex und zu aufgebläht - und trotzdem nicht schneller als das alte 'statische' Booten.

Ich hoffe - wie gesagt - auf systemd. Sieht so aus, als ob das von Grund auf neu entwickelt worden ist, nicht an Vorhandenes drangehängt. Nur derzeit erscheints mir noch zu buggy.

[not]

Ich hoffe - wie gesagt - auf systemd. Sieht so aus, als ob das von Grund auf neu entwickelt worden ist, nicht an Vorhandenes drangehängt. Nur derzeit erscheints mir noch zu buggy.

Buggy? Wie kannst du es wagen Lennart Poettering, der uns solche Perlen wie PulseAudio geschenkt hat, zu unterstellen, dass Software an der er arbeitet Fehler beinhaltet?

[cosmac]

Das Zeug ist einfach viel zu komplex und zu aufgebläht - und trotzdem nicht schneller als das alte 'statische' Booten.

Ich hoffe - wie gesagt - auf systemd.

kann es sein, dass du sysvinit und systemd vertauscht hast? systemd ist doch das Musterbeispiel für komplexe und aufgeblähte Software. Alleine die Idee, init und cron in ein Programm zu packen, nur weil beide andere Programme starten können... Und dann gibt's keine init-Scripte und /etc/rc*.d mehr; ich glaube nicht, dass die service files einfacher zu verstehen sind als die LSB-Header. Na gut, es gibt wohl einen Kompatibilitätsmodus für vorhandene init-Scripte -- was war noch gleich komplex? Spannend ist auch, wie abhängig systemd von dbus wird; spaßige Sache auf einem Server.

Schau dir den systemd mal genauer an, es gibt ja auch wheezy-Pakete.
http://www.heise.de/open/artikel/Das-In ... 63259.html

Ach ja, ein paar der grundlegenden Ideen zu systemd gefallen mir ausgezeichnet, aber leider konnte da jemand nicht rechtzeitig aufhören