• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]Runlevel=Reihenfolge der Dienste beim Starten ändern

L

lord_icon

Newbie
Hi,

ich hab ein kleines Problem.
Jedes mal wenn ich meine Kiste neuboote, habe ich meist +2h in meinen Loggs drin.
Grund hierfür (zumindest vermute ich das) ist, das ntpd recht spät gestartet wird.

Ich würde diesen nun gern gleich nach dem hochfahren des Netzwerkdienste legen wollen.
Zwischen Netzwerkdienste <=> ntpd kommen u.a. Postfix/Dovecot/syslog-ng

Laden tue ich Runlevel 3-Modus.
Ergo /etc/rc.d/rc3.d/

Dort habe ich derzetig folgendes drin:
Code: 
lrwxrwxrwx 1 root root  9  3. Jan 2009  K01auditd -> ../auditd
lrwxrwxrwx 1 root root  7  3. Jan 2009  K01cron -> ../cron
lrwxrwxrwx 1 root root  7  3. Jan 2009  K01cups -> ../cups
lrwxrwxrwx 1 root root 19  3. Jan 2009  K01network-remotefs -> ../network-remotefs
lrwxrwxrwx 1 root root  7  3. Jan 2009  K01nscd -> ../nscd
lrwxrwxrwx 1 root root  9  3. Jan 2009  K01random -> ../random
lrwxrwxrwx 1 root root  9 30. Okt 00:15 K01rsyncd -> ../rsyncd
lrwxrwxrwx 1 root root 12 20. Jan 2009  K01saslauthd -> ../saslauthd
lrwxrwxrwx 1 root root 15  3. Jan 2009  K01splash_early -> ../splash_early
lrwxrwxrwx 1 root root  7  3. Jan 2009  K01sshd -> ../sshd
lrwxrwxrwx 1 root root 15 30. Okt 01:01 K01stopblktrace -> ../stopblktrace
lrwxrwxrwx 1 root root 22 22. Jan 2009  K01SuSEfirewall2_setup -> ../SuSEfirewall2_setup
lrwxrwxrwx 1 root root  9 22. Jan 2009  K01vsftpd -> ../vsftpd
lrwxrwxrwx 1 root root 10 30. Okt 01:01 K02apache2 -> ../apache2
lrwxrwxrwx 1 root root  8  3. Jan 2009  K02fbset -> ../fbset
lrwxrwxrwx 1 root root 12  3. Jan 2009  K02haldaemon -> ../haldaemon
lrwxrwxrwx 1 root root  6 30. Okt 01:01 K03ntp -> ../ntp
lrwxrwxrwx 1 root root 10 30. Okt 01:01 K03postfix -> ../postfix
lrwxrwxrwx 1 root root 10 30. Okt 01:01 K04dovecot -> ../dovecot
lrwxrwxrwx 1 root root  8 30. Okt 01:01 K04named -> ../named
lrwxrwxrwx 1 root root  8 30. Okt 01:01 K05mysql -> ../mysql
lrwxrwxrwx 1 root root 10 30. Okt 01:01 K07rpcbind -> ../rpcbind
lrwxrwxrwx 1 root root 10 30. Okt 01:01 K08network -> ../network
lrwxrwxrwx 1 root root 12 30. Okt 01:01 K08syslog-ng -> ../syslog-ng
lrwxrwxrwx 1 root root  7 30. Okt 01:01 K09dbus -> ../dbus
lrwxrwxrwx 1 root root 21 30. Okt 01:01 K09SuSEfirewall2_init -> ../SuSEfirewall2_init
lrwxrwxrwx 1 root root  7  3. Jan 2009  S01dbus -> ../dbus
lrwxrwxrwx 1 root root  8  3. Jan 2009  S01fbset -> ../fbset
lrwxrwxrwx 1 root root  9  3. Jan 2009  S01random -> ../random
lrwxrwxrwx 1 root root 21 22. Jan 2009  S01SuSEfirewall2_init -> ../SuSEfirewall2_init
lrwxrwxrwx 1 root root 12 30. Okt 01:01 S01syslog-ng -> ../syslog-ng
lrwxrwxrwx 1 root root  9 30. Okt 01:01 S02auditd -> ../auditd
lrwxrwxrwx 1 root root 12  3. Jan 2009  S02haldaemon -> ../haldaemon
lrwxrwxrwx 1 root root 10  3. Jan 2009  S02network -> ../network
lrwxrwxrwx 1 root root 10 30. Okt 01:01 S03rpcbind -> ../rpcbind
lrwxrwxrwx 1 root root 15 30. Okt 01:01 S03splash_early -> ../splash_early
lrwxrwxrwx 1 root root  8 30. Okt 01:01 S06mysql -> ../mysql
lrwxrwxrwx 1 root root  8 30. Okt 01:01 S06named -> ../named
lrwxrwxrwx 1 root root 19 30. Okt 01:01 S06network-remotefs -> ../network-remotefs
lrwxrwxrwx 1 root root  9 30. Okt 01:01 S06rsyncd -> ../rsyncd
lrwxrwxrwx 1 root root 12 30. Okt 01:01 S06saslauthd -> ../saslauthd
lrwxrwxrwx 1 root root  7 30. Okt 01:01 S06sshd -> ../sshd
lrwxrwxrwx 1 root root  9 30. Okt 01:01 S06vsftpd -> ../vsftpd
lrwxrwxrwx 1 root root  6 30. Okt 01:01 S07ntp -> ../ntp
lrwxrwxrwx 1 root root  7 30. Okt 01:01 S08cups -> ../cups
lrwxrwxrwx 1 root root 10 30. Okt 01:01 S08dovecot -> ../dovecot
lrwxrwxrwx 1 root root  7 30. Okt 01:01 S08nscd -> ../nscd
lrwxrwxrwx 1 root root 10 30. Okt 01:01 S09postfix -> ../postfix
lrwxrwxrwx 1 root root 10 30. Okt 01:01 S10apache2 -> ../apache2
lrwxrwxrwx 1 root root  7 30. Okt 01:01 S11cron -> ../cron
lrwxrwxrwx 1 root root 15 30. Okt 01:01 S12stopblktrace -> ../stopblktrace
lrwxrwxrwx 1 root root 22 30. Okt 01:01 S12SuSEfirewall2_setup -> ../SuSEfirewall2_setup

Nun meine Frage:
Wenn ich mich im Web richtig belesen habe, stellt diese Reihenfolge auch die Bootreihenfolge dar, da diese Alpabetisch "abgearbeitet" wird.

Ist es ausreichend, wenn ich einfach die Namen vorne ändere oder bekomme ich dann Probleme beim Booten ?

Danke
 
A

Anonymous

Gast
lord_icon schrieb:
Wenn ich mich im Web richtig belesen habe, stellt diese Reihenfolge auch die Bootreihenfolge dar, da diese Alpabetisch "abgearbeitet" wird.

Ist es ausreichend, wenn ich einfach die Namen vorne ändere oder bekomme ich dann Probleme beim Booten ?
Zum Vergrößern anklicken....
Das war mal ;) Die Scripte in modernen Linuxen werden heute per default parallel gestartet, das heißt, bei mehr als einer CPU werden die Scripte mit allen verfügbaren CPUs parallell gestartet. Selbst bei nur einer CPU kommt es zu Parallelen, weil während der Laufzeit eines Scriptes schon ein anders abgearbeitet werden kann und nicht jedes Script immer warten muss bis ein anderes fertig ist. Die Reihenfolge dort unterhalb von /etc/init.d/rc?.d zu ändern ist vergebliche Mühe, weil das normalerweise überhaupt keine Auswirkungen mehr hätte und anderer Seite das sowieso bei nächster Gelegenheit von Yast wieder geändert würde. Die Abhängigkeiten und die Reihenfolge wird einzig durch die 3 Dateien
Code: 
/etc/init.d/.depend.boot
/etc/init.d/.depend.start
/etc/init.d/.depend.stop
gesteuert, und die sind für den Normaluser kaum zu interpretieren und ein manuelles direktes Ändern dieser Dateien so auch nicht möglich.
http://www.linupedia.org/opensuse/Bootvorgang#Starten_der_Runlevel
http://www.linupedia.org/opensuse/Runlevel_scripte_-_Scripts_selbst_erstellen

Was du beschreibst sieht irgendwie nach Konfigurations-Misch-Masch aus. Für solche Zeitsprünge wie du sie beschreibst, gibt es 2 wahrscheinliche Gründe, entweder deine Hardwareuhr wird nicht, oder nicht richtig synchronisiert, oder du verwendest 2 verschiedene Zeitrechnungen auf einem Rechner. http://www.linupedia.org/opensuse/Uhrzeit_Korrektur#Zwei_Arten_der_Zeitangabe

NTPD dürfte solche extremen Zeitsprünge nicht erzeugen.
Also im BIOS in eventuell anderen Betriebssystemen und im Linux prüfen das immer und überall mit der selben Zeitrechnung gearbeitet wird. In Suse ist es die Datei /etc/sysconfig/clock
der Abschnitt (hier im Beispiel konfiguriert auf Lokalzeit)
Code: 
# Set to "-u" if your system clock is set to UTC, and to "--localtime"
# if your clock runs that way.
#
HWCLOCK="--localtime"
gleiche Datei die Option "SYSTOHC=" sollte auf yes stehen, damit beim Beenden die aktuelle Zeit in den BIOS geschrieben wird. Und die Zeitzonen sollte nicht in einem Betriebssystem auf Kanada und im anderem Betriebssystem auf Berlin stehen ;)
und dann die Zeit richtig stellen (eventuell vorher nochmal den ntpd stoppen und die Zeit per Hand übers Internet syschronisieren.
Code: 
ntpdate de.pool.ntp.org  de.pool.ntp.org  de.pool.ntp.org
und dann ntpd wieder starten) danach die Datei /etc/adjtime löschen und nach dem nächsten Reboot sollte es eigentlich sauber laufen.

robi
 
OP
L

lord_icon

Newbie
Hi Robi,

interessant zu wissen. (das mit den Ablauf von Diensten)

Das mit der Hardware Uhr ist bei Linux respektive bei XEN so eine Sache.
Das ist ein Bug der sich schon seit mehr als 2 Versionen mit sich zieht.

Xen selbst kann nicht auf die Hardeware Uhr zugreifen bzw. diese Ändern.
Das war bis adto auch nciht nötig, da es ja NTD gibt.

ICh hab jetzt mal über Yast/Runlevel NTD deaktiviert und danch nochmal neu aktiviert.
lrwxrwxrwx 1 root root 6 30. Okt 21:09 K02ntp -> ../ntp
lrwxrwxrwx 1 root root 6 30. Okt 21:09 S07ntp -> ../ntp
Zum Vergrößern anklicken....

ALT... zum Vergleich:
Code: 
lrwxrwxrwx 1 root root  6 30. Okt 01:01 K03ntp -> ../ntp
lrwxrwxrwx 1 root root  6 30. Okt 01:01 S07ntp -> ../ntp


Ich werde jetzt nich n paar Stunden warten und dann mal n Reboot machen (is n Produktives System)
Auf der einen Seite Danke ich dir für diese Ausführliche Erklärung... hoffe aber, das es doch in einer gewissen Reihenfolge abgearbeitet wird... (i hope so)
 
J

josef-wien

Ultimate Guru
ntp ändert die Systemuhr, aber nicht die Hardware-/BIOS-Uhr.

robi schrieb:
In Suse ist es die Datei /etc/sysconfig/clock
Zum Vergrößern anklicken....
Dazu ist es aber erforderlich, daß das jeweilige Init-Skript aktiv ist. Üblicherweise erledigt boot.clock sowohl beim Hochfahren "Read hardware clock and set system clock" als auch beim Herunterfahren "Read system clock and set hardware clock", bei openSUSE 11.0 ist jedoch boot.clock für den ersten Teil und boot.getclock für den zweiten Teil zuständig.

lord_icon schrieb:
hoffe aber, das es doch in einer gewissen Reihenfolge abgearbeitet wird
Zum Vergrößern anklicken....
Die Reihenfolge ist durch die Summe aller Definitionen in den betroffenen Init-Skripten vorgegeben ("Required-Start:" usw.).
 
OP
L

lord_icon

Newbie
DER ausschlaggebende TIPP


bei openSUSE 11.0 ist jedoch boot.clock für den ersten Teil und boot.getclock für den zweiten Teil zuständig.
Zum Vergrößern anklicken....
Okay... boot.clock habe ich drin.
boot.getclock = leider nicht. Soll das der Fehler sein ?

Also wird beim runterfahren die Zeit nicht gesetzt (was unter Xen auch nicht möglich ist)
Beim nächsten hochfahren kann dann keine aktuelle Zeit vorgefunden werden und deshalb wird die HWCLOCK Zeit verwendet.


Deshalb hatte ich das hier immer bekommen
Dovecot startet beim Booten zwar... schmiert dann aber ab:
Code: 
Starting dovecot Warning: Last died with error (see error log for more information): Time just moved backwards by 6993 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards

ntpd log sagt:
Code: 
31 Oct 03:15:23 ntpd[2390]: restrict requires an address
31 Oct 03:15:24 ntpd[2390]: Listening on interface #9 eth1, fe80::216:3eff:fe0d:534#123 Enabled
31 Oct 03:15:24 ntpd[2390]: new interface(s) found: waking up resolver
31 Oct 03:15:32 ntpd[2390]: synchronized to 80.153.14.198, stratum 2
31 Oct 01:18:58 ntpd[2390]: time reset -6993.992032 s
31 Oct 01:18:58 ntpd[2390]: kernel time sync status change 0001
31 Oct 01:20:20 ntpd[2390]: ntpd exiting on signal 15

Lösung:
ich habe einfach die Datei K04boot.clock-Datei gelöscht...

Somit hat er anscheind nach dem Reboot keine Möglichkeit gehabt, die HWCLOCK-Time zu holen und verwendet dann die ntp Zeit
 
J

josef-wien

Ultimate Guru
Wenn Du einen Dienst entfernst, dann mache das ordentlich:
Code: 
insserv -r boot.clock
Ob Dein Weg richtig ist, wage ich zu bezweifeln, auf jeden Fall ist der Unterschied der Initialzeit zur ntp-Zeit dann noch größer.

lord_icon schrieb:
was unter Xen auch nicht möglich ist
Zum Vergrößern anklicken....
Das wundert mich. Bei einer virtuellen Maschine geht es natürlich nicht, beim Hauptsystem sehe ich keinen Hinderungsgrund. Das ist schließlich nichts anderes als eine Anweisung an das BIOS. Das Programm hwclock steckt im Paket util-linux, da gibt es keine spezielle XEN-Version.
 
OP
L

lord_icon

Newbie
Dom0 = da ist das korrekt. Die kann das nutzen.
Bei DomU (gäste) geht das nicht.


Und zum "sauberen löschen"
Hatte ich auch erst versucht. Aber daran sind leider abhängkeiten gebunden.

insserv -r boot.clock
insserv: Service boot.clock has to be enabled to start service cron
insserv: Service boot.clock has to be enabled to start service smtp
insserv: exiting now!
Zum Vergrößern anklicken....

Beide Dienste brauche ich logischerweise. Drum mußte ich den "unsauberen" Weg nehmen.

Es sei denn, du hast noch einen Trick18 in der Tasche, wo ich diese Abhänigkeiten lösen kann.
 
J

josef-wien

Ultimate Guru
lord_icon schrieb:
Dom0 = da ist das korrekt. Die kann das nutzen.
Bei DomU (gäste) geht das nicht.
Zum Vergrößern anklicken....
Dann stimmen wir ja überein:
josef-wien schrieb:
Bei einer virtuellen Maschine geht es natürlich nicht, beim Hauptsystem sehe ich keinen Hinderungsgrund.
Zum Vergrößern anklicken....
lord_icon schrieb:
Trick18
Zum Vergrößern anklicken....
Nachdem wir es mit Linux zu tun haben, fallen mir einige Sachen ein. Ich behalte sie aber für mich, da sie nicht ganz ungefährlich sind und vor allem zur Lösung nicht beitragen.

Auch ohne K04boot.clock holt sich Linux die Zeit vom BIOS (oder vom Hauptsystem "Dom0"), interpretiert sie aber hinsichtlich "UTC/Localtime" anders. Dein Problem muß damit zu tun haben, daß die Zeitsynchronisation zwischen "Dom0" und "DomU" nicht paßt. Vielleicht kann Dir das Forum http://www.linux-club.de/viewforum.php?f=43 weiterhelfen.

Erweitere noch den Betreff Deines ersten Beitrags um: [gelöst]
 
T

Tooltime

Advanced Hacker
josef-wien schrieb:
Auch ohne K04boot.clock holt sich Linux die Zeit vom BIOS (oder vom Hauptsystem "Dom0"), interpretiert sie aber hinsichtlich "UTC/Localtime" anders.
Zum Vergrößern anklicken....
Das sehe ich ein bisschen anders da mir nicht einleuchten will, wie der Link für ein Stop-Script das Startverhalten eines Systems beeinflussen soll.

Mich würde man interessieren ob die Zeit stimmt wenn nach dem Booten boot.clock start manuell aufgerufen wird.
 
OP
L

lord_icon

Newbie
na aber gern doch :->

/etc/init.d/boot.clock status => sagt schon mal "unknown"

/etc/init.d/boot.clock start => Setting up the system clockSetting up timezone data

date => korrekte Zeitausgabe

/etc/init.d/boot.clock status => gibt immer noch "unknown" aus.


/etc/init.d/boot.clock stop =>
Set Hardware Clock to the current System TimeCannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
 
T

Tooltime

Advanced Hacker
lord_icon schrieb:
/etc/init.d/boot.clock start => Setting up the system clockSetting up timezone data
date => korrekte Zeitausgabe
Zum Vergrößern anklicken....
Nur das hat mich interressiert, sieht für mich hiernach aus:
Das Problem konnte ich reproduzieren wenn das System nach der Installation neu gestartet wird ohne die aktuellen Updates einzuspielen. Oder alternativ, wie ich es früher gemacht habe, schon bei der Installation das Update-Repo einbinden damit gleich die aktuellen Pakete installiert werden, auch das geht schief.
 
J

josef-wien

Ultimate Guru
Tooltime schrieb:
Das sehe ich ein bisschen anders da mir nicht einleuchten will, wie der Link für ein Stop-Script das Startverhalten eines Systems beeinflussen soll.
Zum Vergrößern anklicken....
Als Beispiel habe ich einfach die von lord_icon genannte Datei K04boot.clock geschrieben (die aber im vorliegenden Zusammenhang die falsche war). Ich wollte zum Ausdruck bringen, daß sich openSUSE die Zeit auch dann vom BIOS holt, wenn das Init-Skript boot.clock beim Systemstart garantiert nicht aufgerufen wird.

Die "alternative Logik" reagiert aber anders als die Logik in boot.clock. Bei mir verwendet openSUSE dann die um 1 Stunde erhöhte BIOS-Zeit. Eine mögliche Erklärung wäre, daß die "alternative Logik" die BIOS-Zeit als UTC annimmt und deswegen um 1 Stunde erhöht, weil meine openSUSE-Zeit als Lokalzeit definiert ist. Wenn ich dann im laufenden System boot.clock manuell durchführe, wird die Zeit um 1 Stunde reduziert und entspricht somit wieder genau der BIOS-Zeit (was auch logisch ist, da boot.clock das Programm hwclock verwendet).

P.S. Bei lord_icon wird der THEN-Zweig der Abfrage if test "$HOSTTYPE" = "s390" -o "$HOSTTYPE" = "s390x" ; durchlaufen, bei mir ist es der ELSE-Zweig. Vielleicht hängt das Problem von lord_icon auch damit zusammen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben