FreeBSD 5.4 bootet automatisch neu

B

binaer

Well-Known Member
Hallo zusammen

Unsere neuen FreeBSD-Server (5.4) haben folgendes Problem:
Sie bootet unregelmässig von selber neu. Davor steht eine Hardware-Firewall.
In den Log-Files ist nichts zu finden.

Server:
Dell PowerEdge 2850, Dual-CPU (Funktioniert, in den Kernel so eingebaut), 2GB Memory.

Hat jemand einen Tipp?

Grüsse
binaer
 
Ich würde in diesem Fall nicht auf die Software tippen, sondern eher auf die Hardware. In deinem Fall würde ich mir den Bereich "Netzteil und Verkabelung" mal genau ansehen, es klingt imho ein wenig nach einem abgerauchten Netzteil.
 
hmm... es ist aber alles redundant aufgebaut... sprich: 2x Netteil...

Einen guten Rutsch wünsche ich Dir und danke Dir, für deinen Tipp!
 
Also Dell hatte schon zumindest eine Rückrufaktion für Rechner
dieser Serie mit solchen Problemen. Ob das
bei dir relevat ist weiss ich nicht.
So, jetzt muss man aber auch eingestehen das die fünferreihe von freebsd
probleme hat/hatte mit der SMP geschichte.
Da könnte man jetzt überall die loggingaktivitäten erhöhen
und hoffen das man dann irgend etwas findet.

Versuch mal eine aktuelle 6er Version und berichte uns bitte.

Ja,und an guten Rutsch,allerseits :D

MfG nap
 
Nun, da es sich um einen produktiven Server handelt, ist es nicht einfach mal so schnell auf 'ne 6er Version umzusatteln... ;-)
 
bringt eigentlich ein background_fsck="YES" etwas? Wenn nein, wie kann ich die Festplatte beim booten prüfen lassen?

Ich werde einmal mit DELL Kontakt aufnehmen. Ich lass Euch wissen, was dabei herausgekommen ist...

Grüsse
binaer
 
Ein frohes neues Jahr.
nur eine Frage, was ist ein background_fsck="YES" ?
wird dabei das Filesystem im Hintergrund gecheckt?
Sry bin neu auf dem BSD gebiet.
 
Naja ein Produktionsserver der mal einfach so rebootet is aber auch
kein Zustand,zumindest ned wenns a *BSD-Server is. ;)
Viel Glück auf alle Fälle.

@<===|~Phlummi~>
Ja,mit backgroud_fsck="YES"
wird wenn möglich das Dateisystem im Hinterzimmer ohne
großes aufsehen untersucht,
und wenn du möchtest das der check erst
30 Sekunden nach dem booten startet verwendest du
backgroud_fsck_delay="30".
So circa halt. :)

MfG nap
 
Bei diesen Dells habe ich schon mehrfach von Problemen im Bezug auf den eingebauten Raid-Controller gehört.

Wenn FreeBSD mehrfach Timeouts bekommt, wenn es nicht auf Platte schreiben kann (nur "/" ?), dann macht er einen Reboot.

Da er in dem Fall auch keine Syslogmessages wegschreiben kann, gibt's auch keine Fehlermeldung. Dazu muss man den Syslog auf eine andere Maschine schreiben lassen.
 
Der syslogd läuft im nomalfall schon.
Das folgende ist ein Auszug einer syslog.conf
Code: 
# Everybody gets emergency messages, plus log them on another
     # machine.
     *.emerg						     *
     *.emerg						     @arpa.berkeley.edu
Links steht welche art von Meldung.
Rechts siehst du wohin die emerg Meldungen geschrieben werden.
---
A hostname (preceded by an at (``@'') sign). Selected messages are
forwarded to the syslogd(8) program on the named host.
---
... und das ist aus der syslog.conf(5) Man-page.

MfG nap
 
Hallo zusammen

Syslogd wurde bereits anfangs Jahr entsprechend konfiguriert. Der letzte Reboot ist nun wieder eine Woche her (zuvor 31.12.05). Allerdings gab mir der Syslog-Server leider kein einziges Resultat.

syslog.conf

*.emerg @<IP des Syslog-Servers>
Zum Vergrößern anklicken....

und anbei noch eine allfällige Fehlerquelle:
pid 32672 (identify), uid 1139: exited on signal 11 (core dumped)
pid 32674 (identify), uid 1139: exited on signal 11 (core dumped)
smb_iod_recvall: drop resp with mid 59249
smb_iod_recvall: drop resp with mid 59264
smb_iod_recvall: drop resp with mid 2879
Zum Vergrößern anklicken....

Hat noch jemand eine Idee? Ein Upgrade auf eine 6.x-Version kommt zur Zeit leider aus verschiedenen, technischen, Gründen nicht in Frage.

Grüsse
binaer
 
Hi also ich hatte hier an Weihnachten eine PowerEdge 4400 (oder so ähnlich) 2x 667Mhz mit FBSD 6 die auch "einfach" so rebootet hatte bei mir war das raid am abrauchen und hat dann relativ schnell eine nach der andern platte gefressen (Alle platten sind noch orginal und standen nach ein paar Jahren Betrieb ein halbes Jahr still).

Seit ich jetzt neue Platten drinn hab alles wunderbar.

Sheky
 
binaer schrieb:
Syslogd wurde bereits anfangs Jahr entsprechend konfiguriert. Der letzte Reboot ist nun wieder eine Woche her (zuvor 31.12.05). Allerdings gab mir der Syslog-Server leider kein einziges Resultat.
Zum Vergrößern anklicken....

Hallo, bist Du Dir sicher dass der Server einfach bootet? Könnte es nicht sein, dass er durch Panik neu startet?

Um einen Softwarefehler gänzlich auszuschließen solltest Du, falls noch nicht geschehen, eine Konsole anschließen, entweder einen Bildschirm, eine serielle Konsole oder per Firewire. Im Falle einer Panik wird nichts mehr im Syslog stehen.
 
Hallo community

Habe mal wieder News.

Letzthin hat sich einer der betroffenen Server (verschiedene DELL-Server, alle frisch aufgesetzt (damals)) so verabschiedet dass einer ins RZ torkeln durfte.

Es gab dann eine schöne Fehlermeldung:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic 14 = 00
fault virtual address = 0x24
fault code = supervisor read, page not present
[... und so weiter]

allenfalls anhand dieser Meldungen vielleicht Hilfe möglich?

Wie gesagt, es sind verschiedene Modelle, einige liefen zuvor mit 5.3 mehr oder weniger Problemlos. (Bei 5.3 gab es offenbar Probleme mit der Netzwerkkartenkompatibilität, alle paar Monate verabschiedete sich die Verbindung bis zum Tausch zu einer Realtek (war nur Testweise, lief danach jedoch viel besser).

Die andere Kiste ist Fabrikneu und wurde dann auf 5.4 aufgesetzt. Beide Maschinen zeigen die Reboots übrigens nur aufgrund hoher Last. Die eine Maschine bootet viel weniger oft (hat weniger Last) als die andere.

Grüsse
binaer
 
Nein, die Fehlermeldung wird kaum etwas nützen. Trap 12 tritt an allen möglichen Stellen auf, da müsstest du schon anders weiter eingrenzen. Hast du vielleicht einen Kerneldump oder sowas?
 
Hallo community

Leider war es mir bislang noch nicht möglich, den Kernel neu zu kompilieren. Allerdings habe ich Hinweise erhalten dass ein entsprechendes deaktivieren des USB's die Reboots beenden könnte. Da USB eigentlich so oder so deaktiviert sein sollte (durch den Kernel) ich die entsprechende Option im Kernel jedoch nicht auskommentiert hatte bleibt mir nun die Möglichkeit, dies über rc.conf zu tun.

Spricht da irgendetwas dagegen?

usbd_enable="NO"

Grüsse
binaer
 
Schönen guten Morgen

Bei meinem Heimserver habe ich über exakt gleichen Eintrag meine USB-Anschlüsse stillgelegt. Konnte keine negativen Auswirkungen feststellen, obwohl sich die Hardware ein Wenig von Deiner unterscheidet ;)

Greets, s_e
 
gibts 'ne Möglichkeit, die rc.conf auch ohne reboot neu zu laden (bzw. den USB zu deaktivieren?)
 
Nein die rc.conf lässt sich nicht ohne weiteres neu einlesen.
usbd_enable="NO" kannst du aber ohne Probleme eintragen.
Der Eintrag sorgt nur dafür das USBD(8) gestartet bzw. nicht gestartet wird durch /etc/rc.d/ubsd.
Du kannst also einfach im Nachhinein den usbd Prozess mit `/etc/rc.d/ubsd stop` beenden oder mit Hand abschiessen...
 
Hellou

Danke für die Antworten. Ich habe das nun auf den Systemen gemacht und werde mal weiterhin beobachten. Bin nun mit DELL ebenfalls in Kontakt, die haben allenfalls noch weitere Ideen.

Ich melde mich wieder, sobald ich mehr sehe.

Grüsse
binaer
 
Mit usbd_enable="NO" deaktivierst du ja nur den USB-daemon, nicht aber das USB Subsystem als ganzes. Da es sich beim Rest aber um Kernel-Module handelt, genügt das NICHT um USB wirklich zu deaktivieren. Du wirst nicht umhinkommen, den Kernel neu zu backen und zu rebooten, wenn du USB gänzlich deaktivieren willst.

Im GENERIC für 6.0 ist USB fest im Kernel eingebaut:

Code: 
device          uhci            # UHCI PCI->USB interface
device          ohci            # OHCI PCI->USB interface
device          ehci            # EHCI PCI->USB interface (USB 2.0)
device          usb             # USB Bus (required)
(...und andere...)

HTH & Ciao.
Markus Mann
];-)
 
Hallo

Besten Dank für die Antwort. Vielleicht genügt schon das deaktivieren des USB-Daemons da ja permanent Busabfragen gemacht werden und diese durch das deaktivieren des Daemons verhindert wird.

FreeBSD 5.4:
# USB support
device uhci # UHCI PCI->USB interface
device ohci # OHCI PCI->USB interface
#device ehci # EHCI PCI->USB interface (USB 2.0)
device usb # USB Bus (required)
#device udbp # USB Double Bulk Pipe devices
Zum Vergrößern anklicken....

das müsste dann wohl so aussehen:
# USB support
#device uhci # UHCI PCI->USB interface
#device ohci # OHCI PCI->USB interface
#device ehci # EHCI PCI->USB interface (USB 2.0)
#device usb # USB Bus (required)
#device udbp # USB Double Bulk Pipe devices
Zum Vergrößern anklicken....
 
Habe da noch etwas aus dem dmesg:
--- snip ---
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 6
cpu3 (AP): APIC ID: 7
ioapic0: Changing APIC ID to 8
ioapic1: Changing APIC ID to 9
ioapic1: WARNING: intbase 32 != expected base 24
ioapic2: Changing APIC ID to 10
ioapic2: WARNING: intbase 64 != expected base 56
ioapic3: Changing APIC ID to 11
ioapic3: WARNING: intbase 96 != expected base 88
-- snap --
Zum Vergrößern anklicken....

ob das gesund ist? :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben