ominöse Neustarts FreeBSD 13

medV2

Well-Known Member
Hallo Forum,

vielleicht hat ja von euch jemand eine Idee:

Ich habe letztens einen meiner Server von 12.3 auf 13.0 gehoben. Update lief problemlos. Nun habe ich den Fall, dass sich entsprechender Server regelmäßig neu startet. Es ist immer zur selben Uhrzeit, allerdings nicht täglich. Manchmal täglich, manchmal auch 2-3 Tage.

In den Logs steht nichts, als hätte man den Stecker gezogen. Crontabs oder At-Jobs laufen auch nicht zur fraglichen Zeit.

Jemand auf die schnelle eine Idee dazu bevor ich die ganz schweren debugging Geschütze auffahre?
 
Update lief problemlos. Nun habe ich den Fall, dass sich entsprechender Server regelmäßig neu startet. Es ist immer zur selben Uhrzeit, allerdings nicht täglich.
Da nix in den Logs steht würde ich die Möglichkeit von Kernel-Panics in den Raum stellen (was ja auch dazu führt, das das System neu startet). Was dagegen spricht in die immer gleiche Uhrzeit weil solche Fehler meist random auftreten. Allerdings kann es ja ein (mehr oder weniger regelmäßiges) Ereignis geben was den Panic triggert.
Um dieser Möglichkeit nachzugehen, könnte man Crash Dumps einschalten:
 
Da nix in den Logs steht würde ich die Möglichkeit von Kernel-Panics in den Raum stellen (was ja auch dazu führt, das das System neu startet). Was dagegen spricht in die immer gleiche Uhrzeit weil solche Fehler meist random auftreten. Allerdings kann es ja ein (mehr oder weniger regelmäßiges) Ereignis geben was den Panic triggert.
Um dieser Möglichkeit nachzugehen, könnte man Crash Dumps einschalten:

Ja das mit dem Kernel Crashdump Debugging ist mir bekannt, und hab ich auch schonmal erfolgreich gemacht, das ist aber leider die Art von schwerem Geschütz die ich gern vermeiden würde, da ich das wohl nicht verrechnen kann..
 
Mit dem crashdump hättest du aber zumindest Gewissheit, ob ein panic für die Neustarts verantwortlich ist, oder nicht.
Du brauchst es ja nur aktivieren.

Rob
 
das ist aber leider die Art von schwerem Geschütz die ich gern vermeiden würde
Naja. Was heißt schweres Geschütz. Du brauchst sie ja lediglich einschalten (dumpdir = "/var/crash" in die /etc/rc.conf eintragen) und dann halt irgendwann mal nach gucken, ob sich überhaupt Dumps angesammelt haben.

Wenn nicht, dann brauch man die Richtung gar nicht weiter zu verfolgen und hat zumindest eine Ursache ausgeschlossen.

Wenn ja, dann hat man wenigstens Ansatzpunkt um zu gucken, wo die Ursache tatsächlich liegt. Und selbst das ist mit crashinfo schnell erledigt. Da brauchst Du also erst gar kein Debugger zu starten (es sei denn man muss wirklich in die Tiiefe gehen; aber es ist ja noch gar nicht klar, ob das überhaupt nötig ist; vielleicht wird auch nur ein Treiber identifiziert den man ggf. eh nicht braucht und den wirft man raus und dann ist das Problem vermutlich erledigt; man weiß es vorher halt nicht und nur es deshalb nicht zu machen, weil Debugging nötig sein könnte, finde ich dann auch ein wenig seltsam).

Kurzum: Das ist eine Sache in der initial erst mal nicht viel Aufwand liegt. Die Frage ist ja, was ist die Alternative? Gar nix machen und es einfach so laufen lassen?

da ich das wohl nicht verrechnen kann..
Also wenn Du die 5 Minuten nicht über hast, dann kann man da wohl nix machen. :-)

Nur ich frag' mich dann, warum Du hier im Forum überhaupt fragst. Hier wird Dir bei den dürftigen Anhaltspunkten keiner eine Lösung präsentieren können. Das wird immer auf "guck Dir mal dasunddas an" hinauslaufen. Wenn das aber alles (selbst bei minimalen Aufwand) nicht geht, weil Du es nicht verrechnen kannst, dann kannst Du Dir auch sparen solche Hinweise einzusammeln.
 
Zuletzt bearbeitet:
Naja. Was heißt schweres Geschütz. Du brauchst sie ja lediglich einschalten (dumpdir = "/var/crash" in die /etc/rc.conf eintragen) und dann halt irgendwann mal nach gucken, ob sich überhaupt Dumps angesammelt haben.

Wenn nicht, dann brauch man die Richtung gar nicht weiter zu verfolgen und hat zumindest eine Ursache ausgeschlossen.

Also wenn Du die 5 Minuten nicht über hast, dann kann man da wohl nix machen. :-)

Nein die paar Minuten hab ich natürlich, ich war gedanklich halt schon bei Debugger. Aber es stimmt natürlich, dass mir die Anwesenheit der Dumps auch schon etwas sagt :)

Kurzum: Das ist eine Sache in der initial erst mal nicht viel Aufwand liegt. Die Frage ist ja, was ist die Alternative? Gar nix machen und es einfach so laufen lassen?


Nur ich frag' mich dann, warum Du hier im Forum überhaupt fragst. Hier wird Dir bei den dürftigen Anhaltspunkten keiner eine Lösung präsentieren können. Das wird immer auf "guck Dir mal dasunddas an" hinauslaufen. Wenn das aber alles (selbst bei minimalen Aufwand) nicht geht, weil Du es nicht verrechnen kannst, dann kannst Du Dir auch sparen solche Hinweise einzusammeln.

Einfach weiterlaufen ist garnicht so übel, der Kunde hats noch nichtmal bemerkt, 1-2 Minuten nicht verfügbarkeit der Services alle 2 Tage ist auch nicht sooo das Problem in diesem Fall. Ist halt nicht schön. Weitere Alternativen wären das Rückstellen auf 12.3.

Das Problem ist direkt nach dem Upgrade auf 13.0 aufgetreten, das ist für mich doch ein greifbarer Anhaltspunkt. Ich möchte zwar langwieriges Debugging und entsprechende Arbeiten vermeiden, dass heißt nicht dass ich sie nicht dennoch mal machen würde wenn Zeit vorhanden ist.
 
Hat das Teil einen IPMI/iLO/iDRAC Interface? Evtl. stehen da noch mehr Informationen im Log.
 
Nö, selbst zusammengebaut und 10 Jahre alt, Devise des Kunden: "Billig, Billig, Billig!". War einer der ersten für die ich damals auf eigene Rechnung was gemacht habe, heute würd ich mich nicht mehr darauf einlassen :D
 
Im Zweifel erstmal weiter hoch auf 13-STABLE, was inzwischen fast ein Jahr neuer als 13.0 ist und das Problem vielleicht schon behoben hat.
 
Da kann es auch einfach sein, dass die Lüfter 10kg Wollmäuse umwälzen müssen und das Update nur zufällig als Auslöser angenommen wird und es ein Hitzeproblem ist.

Nö das wäre ein sehr großer Zufall. Und das Ding steht tatsächlich in nem klimatisierten Raum und wenn ich vor Ort bin wäre mir das auch mal aufgefallen.
 
Muss nicht mal der CPU Lüfter sein. Ich hatte 3 mal ein Mainbaord (HP) bei welchem sich die Kühler der Northbridge gelöst hatte. Aktiviere doch mal das Debugging, sonst kommst du vermutlich nicht weiter.
 
...Server regelmäßig neu startet. Es ist immer zur selben Uhrzeit, allerdings nicht täglich. Manchmal täglich, manchmal auch 2-3 Tage.

In den Logs steht nichts, als hätte man den Stecker gezogen....
... Devise des Kunden: "Billig, Billig, Billig!"....:D
Könnte auch das Netzteil sein, mal gegen ein Anderes tauschen.
10 Jahre Dauerbetrieb mit Billignetzteil, wahrscheinlich noch dazu mit Lüfterregelung "leise, leise", sprich "heiss, heiss".
Da verdunstet der Elektrolyt mit der Zeit, und kleinste Sags in der Versorgung veranlassen "mysteriöse Neustarts", da kaum noch Pufferung besteht.

Was schaltet denn der Kunde zu dieser Zeit im Netz ein?
(Muss nicht unbedingt der Kunde selbst sein. Kann auch irgendwas anderes im entsprechenden Niederspannungsstrang hinterm Trafo sein.)
 
Ist halt nicht schön. Weitere Alternativen wären das Rückstellen auf 12.3.
Ich würde evtl. die Idee aufgreifen ein aktuelleres FreeBSD 13 zu probieren. Ein STABLE-Zweig ist normalerweise nicht das, was man haben will. Aber das 13.1 Release lässt ja nicht mehr lange auf sich warten und dürfte Ende April offiziell erscheinen.
Evtl. kann man auch die Zeit einfach noch abwarten, da der Fehler ja offenbar nicht allzu dramatisch ist.

Ein Rückgehen auf 12.3 fände ich jetzt auch eher suboptimal.
 
Ich würde evtl. die Idee aufgreifen ein aktuelleres FreeBSD 13 zu probieren. Ein STABLE-Zweig ist normalerweise nicht das, was man haben will. Aber das 13.1 Release lässt ja nicht mehr lange auf sich warten und dürfte Ende April offiziell erscheinen.
Evtl. kann man auch die Zeit einfach noch abwarten, da der Fehler ja offenbar nicht allzu dramatisch ist.

Ein Rückgehen auf 12.3 fände ich jetzt auch eher suboptimal.
Das ist jetzt auch der Weg den ich einschlage. Crashdumps sind aktiviert und 13-Stable kompiliert gerade.
 
Evtl. macht es Sinn bei der Gelegenheit gleich Boot-Environments zu benutzen. Das ermöglicht einem auch schnelles zurückwechseln, falls es mit der neuen Version Probleme gibt.
 
Alternativ kann man für Tests auch erstmal nur den Kernel aktualisieren und sich die Welt sparen. In Stable-Zweigen klappt das meist.
 
Alternativ kann man für Tests auch erstmal nur den Kernel aktualisieren und sich die Welt sparen. In Stable-Zweigen klappt das meist.

Das meistens macht mir etas angst :D Hab halt keinen physischen Zugriff, bzw. müsste im Fall des Falles erst zum Kunden fahren. Aber vielleicht bin ich mutig jetzt am WE, da wäre ein Ausfall auch nicht schlimm. Irgendwie hält er jetzt auch schon 3 Tage durch..

Evtl. macht es Sinn bei der Gelegenheit gleich Boot-Environments zu benutzen. Das ermöglicht einem auch schnelles zurückwechseln, falls es mit der neuen Version Probleme gibt.

Das System läuft auf GMirror mit UFS.

Vielleicht ist der Grund ja auch ganz profan und die Putze schaltet einfach ihren Staubsauger an.:D

Sowas ähnliches hatten wir in meiner Hauptfirma tatsächlich mal :D Ist hier aber ausgeschlossen.

10 Jahre Dauerbetrieb mit Billignetzteil, wahrscheinlich noch dazu mit Lüfterregelung "leise, leise", sprich "heiss, heiss".
Da verdunstet der Elektrolyt mit der Zeit, und kleinste Sags in der Versorgung veranlassen "mysteriöse Neustarts", da kaum noch Pufferung besteht.

Was schaltet denn der Kunde zu dieser Zeit im Netz ein?
(Muss nicht unbedingt der Kunde selbst sein. Kann auch irgendwas anderes im entsprechenden Niederspannungsstrang hinterm Trafo sein.)

Alles was du schreibst wären gute Hinweise, aber da das Problem direkt nach dem Update auf 13.0 aufgetreten ist, wäre das viel Zufall auf einmal. Auch wenn das Ding "Billig, Billig!" gebaut wurde, so steht es dennoch in nem klimatisierten Raum, bzw. Schrank und hängt an ner USV die auf die Spannung achtet. Das Zeug war zum glück schon da als der Kunde die Räume angemietet hat :). Lüfterregelung gibts auch nicht ;)
 
Das System läuft auf GMirror mit UFS.
Theoretisch kriegt man das auch ohne ZFS hin.
Aber ja. Das machts erst mal schwieriger.

Das meistens macht mir etas angst :D Hab halt keinen physischen Zugriff, bzw. müsste im Fall des Falles erst zum Kunden fahren.
Ja. Das ist echt ungünstig. Ich fühle Dir nach. :-)

Alles was du schreibst wären gute Hinweise, aber da das Problem direkt nach dem Update auf 13.0 aufgetreten ist, wäre das viel Zufall auf einmal.
Naja. Theretisch können es ja auch einfach Nebeneffekte sein. Also das es gar nicht durch Bugs im neuen System kommt, sondern das die neue Version die Hardware einfach anders beansprucht und dann solche Fehler zutage.
 
das will vielleicht nichts heißen: seit etwa einem Monat bin ich nun auf 13.0-p7 und in der Zeit habe ich auch zwei mal erlebt, dass der PC neu gestartet war.
Also normalerweise läuft er durch, aber hier fand ich mich unerwartet am Login-Screen wieder. Das ist zuvor noch nicht vorgekommen.

Ohne diesen Thread hätte ich dem keine weitere Bedeutung beigemessen, denn wir erleben schon längere Stromausfälle, besonders in stürmischen Nächten, wie wir sie ja zu der Zeit häufiger hatten und die USV an meinem PC ist schwächer, als jene an meinem File-Server, der eben keine Probleme zeigte.
Meine apcupsd.events zeigte allerdings auch keine Besonderheiten und nun wundere ich mich ein ganz klein wenig.

Aber zwei Ereignisse in einem Monat ist sicher doch anders zu werten, als die hier behandelte Störung.
 
Also was FreeBSD 13.0.x angeht hab ich auch die Erfahrung mit Kernel-Panics und damit verbundenen Neustarts gemacht. Bei treten die im Zusammenhang mit dem Grafiktreiber (amdgpu). Die treten aber nur sporadisch auf und nur beim booten (und dann beim laden des Treibers).
 
Nun - ich habe hier einen Server unter 13.0-RELEASE-p3 und 2 PC's unter 13.0-RELEASE-p7 - ich habe dieses Verhalten bisher nicht beobachtet.
 
Zurück
Oben