Hi, wie in einem anderen Thread geschrieben, schließt mein Server manchmal einen reboot nicht korrekt ab, d.h. der Kernel läuft und irgendein init-script hängt wahrscheinlich, so dass er nicht alle Services startet, aber keine Fehler loggt oder anzeigt. Leider habe ich den BS dabei noch nie gesehen, weil er bei zig Tests immer korrekt rebootet hat und wenn es sonst auftrat, immer wer einfach auf Power gedrückt hat, dann startet der einen neuen reboot, setzt aber den alten gleichzeitig fort, Kuddelmuddel halt, nach einem weiteren Power startet er dann einfach neu und korrekt. Ich würde das gerne einfach standardmässig mit Uhrzeiten loggen, was man bei vga=normal sieht. Die init-scripte werden ja von startpar gestartet, wobei ich nicht ganz sehe, wie man den output da kriegen kann, möchte ja auch nix verschlimmbessern. Mit tee könnte ich ja vielleicht von eval $(startpar $startopt -M start -P $PREVLEVEL -R $RUNLEVEL) | tee $LOG was abgreifen, aber dann habe ich keine Zeiten. System ist opensuse11.4 evergreen mit allen patches, Kernel 3.0.101-99-desktop, 32bit Danke für jeden Tipp cu jth -- 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
Am Mon, 05 Oct 2015 08:31:46 +0200 schrieb Joerg Thuemmler <listen@vordruckleitverlag.de>: Hallo Jörg!
so dass er nicht alle Services startet, Entschuldigung falls Du das schonmal geschrieben hast. Um welche Services handelt es sich denn?
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.
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)? Was ist im BIOS bei den Punkten Power on/off usw. eingestellt? Ist unter /etc/sysconfig in boot und shutdown alles i.o.? Sind unter /etc/init.d/ die Sym-Links in die einzelnen Runlevel noch i.o.? Gibt es das Problem auch bei einem Neustart mittels init 6 oder shutdown? (Ist vielleicht ne dumme Frage, aber warum immer Power drücken und nicht init 6 oder CTRL-ALT-DEL?)
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):
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. Viele Grüße Matthias -- 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
Am 06.10.2015 um 01:13 schrieb jpr.liste01@jpberlin.de:
Am Mon, 05 Oct 2015 08:31:46 +0200 schrieb Joerg Thuemmler <listen@vordruckleitverlag.de>:
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 <notice -- Sep 28 06:08:44.987804000> service smb start <notice -- Sep 28 06:08:44.989774000> service apache2 start <notice -- Sep 28 06:08:44.990366000> service apcupsd start ... <notice -- Sep 28 06:08:46.658917000> service network start Shutting down (localfs) network interfaces: eth0 device: Sundance Technology Inc / IC Plus Corp IC Plu done eth1 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B eth1 serves root filesystem. Leave it up. skippedShutting down service (localfs) network . . . . . . . . .done <notice -- Sep 28 06:08:49.499422000> service network done <notice -- Sep 28 06:08:49.504738000>. killproc: kill(12414,31) das wird normalerweise nicht geloggt, sondern angezeigt und hier kommen dann die stops mit den starts munter durcheinander...
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
Am Tue, 06 Oct 2015 08:05:36 +0200 schrieb Joerg Thuemmler <listen@vordruckleitverlag.de>: Hallo Jörg! Sehe ich das richtig, daß der Rechner früh eingeschaltet wird und es nicht in einen benutzbaren Zustand schafft und nicht über Nacht gelaufen und irgendwie stehengeblieben ist? Zumindest gehe ich mal davon aus.
ist nicht so ganz klar, weil man dann nicht auf den PC zugreifen kann... Dann bleibt, wenn überhaupt, nur nachträglich boot.omsg.
Nein, das Bootlog hört bei mir immer mit dem mounten auf (auch wenn alles OK ist): Das ist für boot.msg auch i.O.
<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. Das sind, wie auch bei mir, fast die letzten Zeilen aus boot.msg; die nützt hier aber nichts. Interessant ist die boot.omsg. Zumindest bei mir enthält die den gesamten _vorherigen_ Boot- und Shutdown-Vorgang von der HW-Erkenung des Kernels bis zum Abschluß des Shutdowns; ab dem Mounten, wo es für Dich interessant wird, mit Zeitstempel.
Vielleicht bringt es ja irgend einen Hinweis, wenn Du die boot.omsg eines gescheiterten mit der eines erfolgreichen Bootvorgangs vergleichst (evtl. mal hier posten). Möglicherweise läßt sich erkennen, welches Service-Script zwar gestartet aber nicht erfolgreich beendet wurde.
interessanterweise setzt er das im Fehlerfall (nach Drücken des Power-Buttons) einfach fort mit: Da habe ich meine Zweifel, denn die folgenden Zeilen sind zwar nicht vollständig aber völlig i.O. für einen Shutdown (s.u.).
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 <notice -- Sep 28 06:08:44.987804000> service smb start <notice -- Sep 28 06:08:44.989774000> service apache2 start <notice -- Sep 28 06:08:44.990366000> service apcupsd start ... <notice -- Sep 28 06:08:46.658917000> service network start Shutting down (localfs) network interfaces: eth0 device: Sundance Technology Inc / IC Plus Corp IC Plu done eth1 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B eth1 serves root filesystem. Leave it up. skippedShutting down service (localfs) network . . . . . . . . .done <notice -- Sep 28 06:08:49.499422000> service network done <notice -- Sep 28 06:08:49.504738000>. Ich denke, daß hier nichts durcheinander kommt. Das "start" hinter den services kann in die Irre führen. Es besagt lediglich, daß das entsprechende Script gestartet wurde: Beim Shutdown mit der Variablen STOP, beim Booten mit START. Später, wenn das Script abgearbeitet ist, kommt dann sowohl beim Booten als auch beim Shutdown "$SERVICE done".
killproc: kill(12414,31)
das wird normalerweise nicht geloggt, In der boot.omsg geht's bei mir hier weiter.
es klappt ja alles 99 mal... nur beim 100sten nicht, danach ohne Änderung wieder 99 mal OK Solche Fehler liebe ich. ;-)
Vielleicht sind hier ein paar Anregungen für Dich dabei. Viele Grüße. Matthias -- 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
participants (2)
-
Joerg Thuemmler -
jpr.liste01＠jpberlin.de