Hallo miteinander,
letzte Woche habe ich (ich glaub am Freitag war’s) brav meine
SuSE-Kiste mit den angefallenen Updates versehen. Als ich dann am
Abend mein Tagwerk auf die USB-Sicherheitsplatte schaufeln wollte,
tat die keinen Mucks im Betriebssystem (sonst gingen immer gleich
zwei Fenster auf: eins a la /media/usb_platte… und eins a
la /sda1/…).
Nachdem ich in den Logs nachgeforscht hatte, stellte sich heraus,
dass unter anderem auch der hal-Dienst ein update erfahren hatte.
Lief der überhaupt? Ne, natürlich nicht! Also gleich ab in den
Runlevel-Editor, um das Ding wieder zum standardmäßigen laufen zu
bewegen. Hal gestartet, Platte erkannt, Backup gezogen. So weit so
gut.
Nun sollte der hal in den Runleveln 3 und 5 eigentlich wieder
automatisch starten – tut er aber nicht. Wenn ich ihn dann im
Runleveleditor von Hand starte, meckert dieser, das dazu noch cron
und boot.clock (!) laufen müßten. Und hier setzt mein Verständnis
aus. Cron sollte eh schon in den Runleveln 2,3 und 5 laufen. Aber
boot.clock?! Das steht auf B und S – wozu sollte das (wo es doch
schon boot heißt) in einem anderen Runlevel gut sein?
Wie dem auch sei – USB-Datenträger lassen sich seit dem Update
letzten Freitag nur sehr schlecht verwenden. Was kann ich noch tun?
Viele Grüße,
Christian S.
Die betroffene Kiste:
Pentium 4 3,2 GHz 1GB RAM SuSE 9.3 KDE 3.5
Hi,
(bei SuSE graust mir immer etwas…da geht soviel automatisch…
und auch automatisch nicht…
fast wie bei W*ws ;)
Aber mal ein Versuch:
Kist booten, dann mit “ps ax” feststellen, ob cron läuft (der übrigens
auch “fcron”, “acron” oder ähnlich heissen kann…da gibt es mehrere
Derivate.
Wenn nicht: Ersteinmal klären warum nicht. Du scheinst den Bootmechanismus
über /etc/init.d bzw /etc/rc.d verstanden zu haben. Wenn cron nicht laufen
sollte: Per Leveleditor einhängen und versuchen, diesen von Hand zu starten.
Zu boot.clock:
Dieses File startet ein Program namens “hwclock”, dass Gangungenauigkeiten der
CMOS-Uhr korrigieren soll.
hwclock läuft meines Wissen pro Bootvorgang einmal durch, ist also kein
Daemon. Es könnte aber irgendwo ein File hinterlassen der Art “Work done”,
damit andere Programme dieses als Bestätigung nehmen können und sich auf
den korrekten GFang der CMOS-Uhr verlassen können.
Da cron ebenfalls zeitbasiert ist, mach die Meldung von SuSE mal Sinn.
Also: Ziel muss es sein, erst über boot.clock “hwclock” laufen zu lassen und
dann den cron-Daemon zu starten.
Warum allerdings HAL wiederum cron benötigt….na, SuSE wird’s schon wissen.
Ganz nebenbei: Ich habe einmal mit hal und Konsorten herumgespielt und
recht “nette” Seiteneffekte beobachten können: Schließlich war der komplette
Mount-Zirkus durcheinander geraten und ein Reboot fällig.
Meiner Meinung sollte man keine Automounter benutzen: Erst muss diese
Teile zur Mitarbeit bewegen, dann dauert es bis zu dreißig Sekunden, bis die
Teile merken, was da gemountet werden soll und dieser Vrogang bringt jedesmal
das SuSE 9.2 im Büro für kurze Momente zu Stehen und — mal ehrlich — in
der Zeit von Multithreading und Dual-Core Maschinen ist doch etwas wie
“Polling” out of date, oder ?
Die wirklich veraltete Lösung, die aber sauschnell und unschlagbar
unkompliziert und unglaublich leicht wartbar ist: Ein gutes altes
Shell-Script in Kombination mit udev. udev legt das Device an, den Rest
macht man in guter alter Hackermanier von der Kommandozeile aus:
(Beispiel)
CD einlegen
Script “cdon” starten
CD bearbeiten, Daten backuppen, brennen, lesen
Script “cdoff” zum Aushänegen bzw. “cdout” für Aushänegen und Auswerfen
Alles das geht VIEL schneller als halbminutenweise auf den Automounter
zu warten.
Man braucht lediglich die Kommandos “mount” “umount” und “eject” zu diesem
Zwecke.
Ich bin mit dieser zugegebener Maße altmodischen Lösung sehr glücklich.
Oder umschrieben: Ein stinkendes altes aber brennendes Zippo-Feuerzeug
ist mir tausendmal lieber als ein schickes Gasfeuerzeug im Porsche-
Design —- was beim kleinsten Windhauch ausgeht oder gar nicht erst
anspringt.
Nein, ich rauche nicht… :O)
Only my two cent.
Keep hacking,
mcc
Diese Mätzchen waren es, die mich bei der SuSE zum Wahnsinn getrieben haben. Ich habe damals die meisten Automatismen einfach abgeschaltet und die entsprechenden Devices einfach statisch in die fstab eingetragen und auf dem Desktop manuell ein paar Verknüpfungen gelegt. Wenn ein sdx nicht angeschlossen war, dann gibt es halt eine Fehlermeldung, na und? Bei der 9.2 konnte man schneller einen fstab-Eintrag tippen als der SuSE Automatismus das Gerät (vielleicht) nach üblem System-Schluckauf gemountet hatte.
Mein Lieblingstool zum Runlevel-Editieren ist ksysv. Graphisch, übersichtlich und tut was man ihm sagt.
Viel Erfolg.
BEnjamin
Hallo miteinander,
Vielen Dank für Eure Hilfe. Es ist Freitag – Systempflege- und -verstehetag –
und so machte ich mich auf die Spur, wieso da einige Dienste seit dem letzten
Update einfach nicht mehr gestartet werden (den Apache hat’s übrigends auch
erwischt).
a) Runleveleditor:
Dort finde ich
apache2 3, 5
boot.clock B, S
cron 2, 3, 5
hal 3, 5
Hinter allen ein “Nein”, sie laufen also nicht, obwohl sie das eigentlich
sollten – ich bin ja im Runlevel 5.
Ausnahme ist boot.clock, der sollte ja schon beim Booten durchlaufen – das ist
die “Setting up the CMOS clock”-Meldung, nicht wahr? Die kam auch beim Booten,
ich hab drauf geachtet. In der boot.msg ist sie auch zu finden.
b) init.d
Dort findet sich unter boot.d (also /etc/init.d/boot.d) ein Link K14boot.clock
nach ../boot.clock (/etc/init.d/boot.clock) – passt also, denke ich.
Das gleich gilt für hal, cron und apache2 – Link im rc3.d bzw rc5.d und Skript
eins weiter oben. Scheint also alles in Ordnung… In den Skripten selbst will
ich lieber nicht rumfummeln, solange ich da nicht ganz genau weiß, was ich
überhaupt tue.
c) Handstart …
… ist wie oben beschrieben kein Problem. Erst boot.clock, dann cron, dann
hal, apache2 auch gleich mit – dann läuft alles wie gewünscht.
Fazit: Ich hab die boot.msg abgegrast, die messages durchforstet, nirgendwo
ein Hinweis, dass da was nicht so durchgelaufen ist, wie es sollte. Also
bleibt mir nur, weiter zu googlen und zu schauen, ob jemand anderes das
Problem auch schon mal hatte und lösen konnte.
Bis dahin wir der Apache von Hand gestartet und die Platte von Hand gemountet.
Viele Grüße
Christian S.
PS. KSysV sieht hübsch aus – lässt sich aber bei mir nicht mehr schließen.
Hängt vermutlich mit dem 3.5.1-Update zusammen, auch wenn es von SuSE kommt,
scheint da einiges noch nicht so zu passen, wie man sich das wünscht – aber
das ist eine andere Baustelle.
Die betroffene Kiste:
Pentium 4 3,2 GHz 1GB RAM SuSE 9.3 KDE 3.5
Hallo miteinander,
wie sagte Wilhelm Busch einst so schön?
“Dass Schlüsselloch wird leicht vermisst,
wenn man es sucht, wo es nicht ist!”
Ihr ahnt schon, die Lösung des oben genannten Problems hat nichts, aber auch
gar nichts mit hal, USB oder dergleichen zu tun. Nachdem mir im
YaST-Runleveleditor einige Sternchen hinter den widerspenstigen Diensten
aufgefallen waren, legte ich mir davon eine Liste an: völlig ohne Zusammenhang
tummelten sich da der Apache, Samba und NFS und noch einige andere Kollegen.
Auffallend dabei, das waren alles “höherwertige” Kandidaten, die andere
Dienste voraussetzen. Sicherheitshalber notierte ich mir die S-Nummern der
rc5.d.
Man verzeihe mir, dass ich zur Problemlösung die Windows-Holzhammer-Methode
einsetzte – ich deaktivierte kurzerhand alle zickigen Dienste in allen
Runleveln und startete den Rechner neu. Keine Sternchen! OK, ich editierte die
Runlevel wieder auf den gehabten/gewünschten Stand. Neustart!
Welch Wunder! cron lief, hal lief – und beide hatten eine neue S-Nummer in der
rc5.d. Soweit so gut. Der Apache und NFS zickten weiter, hatten aber auch noch
immer verdächtig kleine S-Nummern. Da ich keine Lust hatte, weiter
rumzuprobieren, und mich auf der richtigen Fährte wähnte, spielte ich einfach
mal ein komplettes init.d-Verzeichnis aus dem Backup der vorletzten Woche
zurück. Neustart, um zu testen, wie sich das System beim morgendlichen
Einschalten verhält.
Et voila! – Alles läuft wieder wie es soll!
Wer oder was mir da allerdings die Startskripten durcheinander gewürfelt hat,
wird wohl ein Rätsel bleiben.
Und die Moral von der Geschicht?
Vergesse Deine Backups nicht!
Viele Grüße,
Christian S.
PS.: Was meint der mit S-Nummern?! Siehe hier: [1]