[FreeBSD] gateway crasht random, waar moet ik zoeken?*

[JaQ]

Ik heb een drietal FreeBSD machines "ge-erft" die dienst doen als gateway/firewall/nat oplossing. Dit is ook het enige wat deze machines doen, de load is derhalve laag (zelden boven de 0.1).

Een van deze machines heeft de nare neiging om op random tijdstippen helemaal vast te slaan. Ik kan helaas niet gemakkelijk bij de machine zelf, aangezien deze remote hangt. Het enige wat daarna nog helpt is een via de APC een reboot te dwingen (daarna komt de machine wel gewoon netjes op). Een crash forceren is me nog niet gelukt, dus in het hostingcentrum gaan zitten en gaan kijken naar een scherm heeft weinig tot geen nut.

Zelf heb ik weinig ervaring met FreeBSD en ben geen echte netwerkspecialist, wat de zoektocht tot oplossing van dit probleem enigszins bemoeilijkt. (ik ben wel redelijk ervaren met Linux en Solaris, maar dat is net geen FreeBSD ) De "normale" plaatsen om logging te zoeken lijkt mij /var/log, maar ik kan hier niets vinden omtrent het crashen van de machine, buiten de volgende meldingen om:

code:

Nov 30 07:24:33 gateway-2 /kernel: em3: watchdog timeout -- resetting
Nov 30 07:24:35 gateway-2 /kernel: em3: Link is up 100 Mbps Full Duplex
Nov 30 07:24:58 gateway-2 /kernel: em0: watchdog timeout -- resetting
Nov 30 07:25:00 gateway-2 /kernel: em0: Link is up 100 Mbps Full Duplex

Als ik naar deze melding ga zoeken op internet kom ik meldingen tegen over een driver, maar aangezien ik 3 identieke machines (qua hardware en FreeBSD versie) heb, lijkt me dat sterk.

De versie van FreeBSD is 4.9, ik heb geen flauw idee hoe ik de kernel versie kan achterhalen (uname -a geeft me enkel FreeBSD versie).

Kan iemand me een hint geven in welke richting ik zou kunnen zoeken?

[kenneth]

Een watchdog is een (hw/sw) device dat je computer herstart als het na een gegeven periode geen input ontvangt.

FreeBSD is een compleet systeem. Dat omvat dus de hele userland én de kernel. Handig he

[RagaBaSH]

ik heb tijden lang FreeBSD machines uit de 4.x-RELEASE en STABLE branch gedraaid, en de enige keren dat deze machines crashten was als ik een combinatie had van een kapotte IDE op mijn moederbord en een maxtor HD (heb eigenlijk nooit anders gebruikt, dus weet niet of het met andere merken ook zo werkte).
Reden van de crash was dat de kernel de "sync" met de harde schijf kwijt raakte en niet meer gesynced kreeg. gevolg was een melding op console (nergens anders helaas, ook niet in logs) dat hij paniekte... meestal resulteerde dit in een reboot, tenzij mijn ACPI settings niet goed stonden, dan bleef ie hangen.

Nadeel van deze soort crash is dat ie heel slecht te reproduceren is, het is te proberen door veel discactivity aan te zwengelen, maar ook dan is de tijd tot crash onbepaald... wat het veroorzaakt weet ik niet, maar wat het oploste bij mij was altijd een andere IDE controller of een ander mobo (impliceerd hetzelfde, maar is wat verderstrekkend).

[JaQ]

kenneth schreef op woensdag 30 november 2005 @ 12:27:
Een watchdog is een (hw/sw) device dat je computer herstart als het na een gegeven periode geen input ontvangt.

Dus feitelijk lees ik dat em3 al een tijd geen input krijgt (en daarom herstart). Dat is toch een beetje vreemd, aangezien daar bijna 24/7 verkeer door gaat door een aantal servers (em3 is toch een netwerkkaart !?)

kenneth schreef op woensdag 30 november 2005 @ 12:27:
FreeBSD is een compleet systeem. Dat omvat dus de hele userland én de kernel. Handig he

Als je het weet wel

RagaBaSH schreef op woensdag 30 november 2005 @ 12:57:
Reden van de crash was dat de kernel de "sync" met de harde schijf kwijt raakte en niet meer gesynced kreeg. gevolg was een melding op console (nergens anders helaas, ook niet in logs) dat hij paniekte... meestal resulteerde dit in een reboot, tenzij mijn ACPI settings niet goed stonden, dan bleef ie hangen.

Ik kan helaas hier op afstand niet controleren hoe de ACPI settings staan, maar als ik via de APC een reboot geef, dan komt de machine netjes op. Deze lijken dus goed te staan.

RagaBaSH schreef op woensdag 30 november 2005 @ 12:57:
Nadeel van deze soort crash is dat ie heel slecht te reproduceren is, het is te proberen door veel discactivity aan te zwengelen, maar ook dan is de tijd tot crash onbepaald... wat het veroorzaakt weet ik niet, maar wat het oploste bij mij was altijd een andere IDE controller of een ander mobo (impliceerd hetzelfde, maar is wat verderstrekkend).

Maar als ik 3 identieke machines heb (qua hardware), dan kan het probleem daar toch niet in liggen? Het "grappige" is ook dat de periodes tussen crashes echt compleet random zijn. Ze varieren tussen de 2 uur en 4 weken. Het probleem blijkt al lang te spelen, alleen is er nooit echt aandacht aan besteed (maar ik wil niet nog een keer om 6 uur uit mijn nest gebelt worden ).

Wat ik trouwens ook merk is dat lastlog niet leesbaar is (lijkt wel binair). Dat is m.i. niet normaal !?

[Echnon]

als 1 van 3 identieke machines onvoorspelbaar raar doet dan zou ik het *juist* in kapotte hardware zoeken.

lastlog is zowel onder *BSD en linux binair en kun je lezen met resp lastlogin en lastlog. (man)

[Michael]

Grote kans dat het inderdaad een hardware probleem is. Wat een goede test is, is het draaien van een buildworld. oftewel, cd /usr/src && make -j8 buildworld

[JaQ]

Echnon schreef op woensdag 30 november 2005 @ 14:45:
als 1 van 3 identieke machines onvoorspelbaar raar doet dan zou ik het *juist* in kapotte hardware zoeken.

Daar heb je gelijk in, aangezien ik anders op de andere machines dezelfde problemen zou moeten ondervinden.

Michael schreef op woensdag 30 november 2005 @ 15:33:
Grote kans dat het inderdaad een hardware probleem is. Wat een goede test is, is het draaien van een buildworld. oftewel, cd /usr/src && make -j8 buildworld

Een buildworld zorgt toch voor een complete nieuwe build van mijn systeem? Daarvoor zou ik eerst veel meer over freebsd willen weten voordat ik dat ga doen (en per ongeluk wat vern**k. Nog meer entries in dat unix-foutjes topic zou jammer zijn ) Bovendien "lijkt" het door de melding in het log dat het iets met de netwerkkaart doet, dus dan zou een netwerk-intensieve operatie dus meer nut hebben? (uiteraard is het wel nuttig om dan naast de server te gaan zitten, zodat ik ook daadwerkelijk een scherm kan lezen, niet alleen via ssh dus).

Echnon schreef op woensdag 30 november 2005 @ 14:45:
lastlog is zowel onder *BSD en linux binair en kun je lezen met resp lastlogin en lastlog. (man)

mmm.. dat was me eigenlijk nooit opgevallen. My bad (dat had ik trouwens best kunnen vinden zoals je terecht aangeeft )

[Michael]

JaQ schreef op woensdag 30 november 2005 @ 16:57:

Een buildworld zorgt toch voor een complete nieuwe build van mijn systeem? Daarvoor zou ik eerst veel meer over freebsd willen weten voordat ik dat ga doen (en per ongeluk wat vern**k. Nog meer entries in dat unix-foutjes topic zou jammer zijn ) Bovendien "lijkt" het door de melding in het log dat het iets met de netwerkkaart doet, dus dan zou een netwerk-intensieve operatie dus meer nut hebben? (uiteraard is het wel nuttig om dan naast de server te gaan zitten, zodat ik ook daadwerkelijk een scherm kan lezen, niet alleen via ssh dus).

Nee, met een buildworld compile je alleen de userland opnieuw, er word niks geinstalled. Zolang je geen installworld draait gebeurt er verder niks

[Tha_Butcha]

hardware is het eerste wat in me opkomt (omdat het maar bij 1 bak gebeurt), en dan in die categorie geheugen, reepjes vervangen misschien.

[GrooV]

FreeBSD heeft soms wel eens de neiging om compleet te hangen als een hardeschijf kuren begint te vertonen, dit zou je kunnen checken door een fsck te doen. Geheugen fouten kan je herkennen door kernel panics maar dan zou je server niet 4weken goed blijven draaien test dit anders door een memtest te doen met bootflop.

iig zou je beter kunnen upgraden naar 4.11 of daarna naar 5.4

[Michael]

1 crash per maand door fout geheugen kan prima. Het gaat pas fout als het geheugen intensief wordt gebruikt. Vandaar ook dat een goede test is om een buildworld te draaien.

Als je echter toch gaat upgraden, dan kan je in plaats van 5.4 beter naar 6.0 gaan, aangezien deze stukken beter/stabieler is.

[Klaus_1250]

kenneth schreef op woensdag 30 november 2005 @ 12:27:
Een watchdog is een (hw/sw) device dat je computer herstart als het na een gegeven periode geen input ontvangt. Oorzaak kan verschilldende redenen hebben, maar meestal moet je het in de driver/driver-instellingen zoeken.

Die watchdog-timers herstarten in dit geval niet de computer, maar slechts de netwerkkaart/interface.

Ik kan helaas hier op afstand niet controleren hoe de ACPI settings staan, maar als ik via de APC een reboot geef, dan komt de machine netjes op. Deze lijken dus goed te staan.

ACPI op FreeBSD 4.9? Is dat niet pas bij 5.x erin gekomen?

Als je nieuw bent met FreeBSD, zou ik eens beginnen met upgraden naar 4.11, dat moet met de diverse documentatie wel goed te doen zijn. Er zijn in 4.10 en 4.11 updates geweest aan de em-driver, dus wie weet.
Vergeet ook niet om even de security advisories na te lopen.

[ Voor 68% gewijzigd door Klaus_1250 op 01-12-2005 12:04 ]

[JaQ]

Klaus_1250 schreef op donderdag 01 december 2005 @ 11:50:
Die watchdog-timers herstarten in dit geval niet de computer, maar slechts de netwerkkaart/interface.

en dat is nu precies het probleem. De netwerkkaart wordt opnieuw gestart, maar laat vervolgens geen verkeer meer passeren (voor de buitenwereld "hangt" de machine dus, het is wat mij betreft dus nog maar de vraag of de machine daadwerkelijk hangt. Het ontbreken van fysieke toegang op dat moment tot de machines zorgen er voor dat ik dat ook niet kan bekijken)

Klaus_1250 schreef op donderdag 01 december 2005 @ 11:50:
Als je nieuw bent met FreeBSD, zou ik eens beginnen met upgraden naar 4.11, dat moet met de diverse documentatie wel goed te doen zijn. Er zijn in 4.10 en 4.11 updates geweest aan de em-driver, dus wie weet.
Vergeet ook niet om even de security advisories na te lopen.

Mijn collega's geven de voorkeur aan het vervangen van deze FreeBSD machines door een stel cisco's (of HP's) die hetzelfde kunstje kunnen vertonen, maar aangezien ik verwacht dat ik deze dan ook kan gaan beheren ben ik voorlopig nog tegen (aangezien mijn kennis van cisco exact nul,nul is. Ik weet net hoe je het spelt Een flink aantal nare ervaringen met cisco icm een lading VPN tunnels zorgt er echter voor dat ik voorlopig zeker nog op FreeBSD wil blijven).

Een upgrade naar een nieuwe versie van FreeBSD is zeker het overwegen waard. Ik zal dus maar eens de documentatie induiken, ondanks dat een upgrade naar een nieuwe versie uiteraard geen garantie op resolutie is.

[Echnon]

JaQ schreef op vrijdag 02 december 2005 @ 00:44:
en dat is nu precies het probleem. De netwerkkaart wordt opnieuw gestart, maar laat vervolgens geen verkeer meer passeren (voor de buitenwereld "hangt" de machine dus, het is wat mij betreft dus nog maar de vraag of de machine daadwerkelijk hangt. Het ontbreken van fysieke toegang op dat moment tot de machines zorgen er voor dat ik dat ook niet kan bekijken)

Ahh ok dat was nog niet helemaal duidelijk. Misschien kun je naar de logs kijken of zelf een scriptje maken wat je in een cron job om de zoveel tijd draait ( "echo `date` ik draai nog" >> draai.txt" ofzo ). Als het scriptje gewoon doordraait (of als er gewoon doorgelogd wordt) dan spreekt het vanzelf dat de machine zelf nog gewoon vrolijk doordraaide.

Een upgrade naar een nieuwe versie van FreeBSD is zeker het overwegen waard. Ik zal dus maar eens de documentatie induiken, ondanks dat een upgrade naar een nieuwe versie uiteraard geen garantie op resolutie is.

Misschien kun je de taken van deze machine tijdelijk door de andere 2 laten overnemen, dan geeft dat je de ruimte om die upgrade in alle rust te doen. FreeBSD 5.4 zou ik zeker skippen, dus naar 4.11 of direct naar 6.0 upgraden.

[ Voor 9% gewijzigd door Echnon op 02-12-2005 11:33 . Reden: "scriptsource" toegevoegd, haha ]

[kenneth]

Upgraden naar 6.0 kan afaik alleen vanaf 5.3 dus dan zal je sowieso ene tussenstap moeten maken.