Am 06.10.2015 um 01:13 schrieb jpr.liste01@jpberlin.de:
Am Mon, 05 Oct 2015 08:31:46 +0200 schrieb Joerg Thuemmler
: Hallo Jörg!
Hallo Matthias, ich schreib gleich mal zwischen die Zeilen:
so dass er nicht alle Services startet, Entschuldigung falls Du das schonmal geschrieben hast. Um welche Services handelt es sich denn?
ist nicht so ganz klar, weil man dann nicht auf den PC zugreifen kann...
aber keine Fehler loggt oder anzeigt. Hast Du mal in die boot.omsg geschaut? Dort sind bei mir u.a. alle gestarteten Services mit dem entsprechenden Ergebnis und Datum/Uhrzeit des vorhergehenden Bootvorgangs aufgezeichnet. Nach einem erfolgreichen Bootvorgang nach einem mißglückten müßte dort das Protokoll des mißglückten zu finden sein.
Nein, das Bootlog hört bei mir immer mit dem mounten auf (auch wenn
alles OK ist):
<6>[ 11.914954] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02)
initialised: d
<6>[ 12.851404] EXT4-fs (sda7): mounted filesystem with ordered data
mode. Opt
<6>[ 12.880643] EXT4-fs (sda8): mounted filesystem with ordered data
mode. Opt
<6>[ 12.881926] EXT4-fs (sda3): mounted filesystem with ordered data
mode. Opt
<6>[ 12.886178] EXT4-fs (sda6): mounted filesystem with ordered data
mode. Opt
<6>[ 12.898366] EXT4-fs (sda5): mounted filesystem with ordered data
mode. Opt
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.
interessanterweise setzt er das im Fehlerfall (nach Drücken des
Power-Buttons) einfach fort mit:
Boot logging started on /dev/tty1(/dev/console) at Mon Sep 28 06:08:44 2015
Master Resource Control: previous runlevel: 3, switching to runlevel: 0
Master Resource Control: Running /etc/init.d/before.local
done
dann startet der einen neuen reboot, setzt aber den alten gleichzeitig fort, Das kann ich mir nicht so recht vorstellen, denn dann müßte er ja Informationen über den Boot-Vorgang über einen Neustart hinaus speichern und ein neu geladener Kernel das weiterführen. Eine solche Funktion ist mir zumindest auf dem PC nicht bekannt. Deshalb denke ich versuchsweise mal in andere Richtungen:
Das Drücken von Power führt tatsächlich zu einem echten Reboot (Warmstart, Kernel wird neu geladen)?
naja, es führt zu beidem: 1. wird irgendeine "Blockierung" gelöst, der hängengebliebene Boot wird fortgesetzt und 2. wird ein shutdown eingeleitet, (reboot war wohl falsch, habe oben "switch to runlevel 0" nicht gleich gesehen, reboot wäre ja "6"), das kann wegen der Parallelität der Servicestarts durchaus eine Weile gemeinsam gehen, wie man bei der Netzwerkkarte oben sehen kann...
Was ist im BIOS bei den Punkten Power on/off usw. eingestellt?
keine Ahnung und kann die Kiste jetzt grade nicht runterfahren, aber nehme an: Kurzes Drücken=reboot, langes Drücken=poweroff, sicher hat die Kollegin, die das gemacht hat, länger gedrückt, weil man ja vom reboot zunächst nichts sieht...
Ist unter /etc/sysconfig in boot und shutdown alles i.o.?
es klappt ja alles 99 mal... nur beim 100sten nicht, danach ohne Änderung wieder 99 mal OK
Sind unter /etc/init.d/ die Sym-Links in die einzelnen Runlevel noch i.o.?
s.o.
Gibt es das Problem auch bei einem Neustart mittels init 6 oder shutdown?
nein, nie geschafft, das selbst zu "erzeugen" (Ist vielleicht ne dumme Frage, aber warum immer Power
drücken und nicht init 6 oder CTRL-ALT-DEL?)
mach ich ja nicht. Aber wenn die Kiste früh "gefühlt steht" und ich bin nicht da, kann ich hier niemandem lange Verse machen, die drücken halt den Power-Knopf. Da zu diesem Zeitpunkt ja auch nix wichtiges läuft (laufen kann, da kein ssh, smb, cron anscheinend auch nicht), ist das ja auch ok.
Ich würde das gerne einfach standardmässig mit Uhrzeiten loggen, Vielleicht ist Dir an Deinem Server folgendes möglich (Du hast zwar damit unmittelbar keine Uhrzeit, aber du kannst jeden Schritt beim Booten nachverfolgen):
Hab ich schon durch... leider klappt es ja immer, wenn ich dabei bin...
Wenn Du dem Kernel am Bootpromt "confirm" mitgibst (temporär oder permanent), mußt Du beim Booten den Start eines jeden Dienstes bestätigen.
FLOW_CONTROL macht was ähnliches, setzt aber erst später ein.
Evtl. KERNEL_LOGLEVEL hochsetzen.
werd ich versuchen. Denke aber, bringt nix, Kernel ist ja up und ok. Kann ja aber nichts schaden...
Viele Grüße
Matthias
Hab gestern das "tee" in den startpar-Aufruf des rc-Scripts eingebaut... bringt aber auch nix, der gibt nix aus. Das startpar ein binary ist, komme ich da wohl nicht weiter... eventuell könnte ich die Konsole in eine Datei kopieren lassen. Weiß jemand, was die Anzeige beim Servicestart ist /dev/ttyS0 oder /dev/console oder geht das schon auf stdio, also stdout/stderr und ich kann es mit "1>" und "2>" umlenken? Kann man sowas mit "1|tee datei" bzw. "2|tee datei" umlenken? (muss ich gleich mal probieren, ob das in bash geht...) Ja, ist schon komisch das Ganze. Danke jedenfalls, auch für weitere Tipps, die gern genommen werden. -- www.teddylinx.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org