[Linux] Spontane reboot

[cdgrit]

Ik heb een Debian Linux 3.0 server die ongeveer 2 maand goed heeft gedraaid. De laatste dagen reboot het systeem vanzelf. Dan draait het weer een paar dagen en krijg ik weer een spontane reboot.
Ik kan in de logfiles geen vreemde dingen vinden. Wat wel vreemd is is dat de datum en de tijd van het systeem na de reboot vanzelf ongeveer 8 uur vooruit wordt gezet. Iemand een verklaring?

Iemand enig idee wat ik aan deze spontane reboots kan doen?

[_-= Erikje =-_]

Ik heb een vergelijkbare situatie gehad, toen stonden alle elco's op me moederbord bol. Nieuwe elco's erop en klaar.

[cdgrit]

Zou dit altijd een hardware probleem zijn of kan het ook een configuratiefout in de software zijn? Ik neem toch aan dat de logfiles in het laatste geval dan toch iets moeten aangeven...??

[deadinspace]

Controleer inderdaad je hardware eens... Probeer het eens te stressen met bijvoorbeeld cpuburn of memtest86.

cdgrit schreef op 18 juni 2003 @ 14:24:
Zou dit altijd een hardware probleem zijn of kan het ook een configuratiefout in de software zijn?

Het kan ook een software probleem zijn, maar dat lijkt me gezien de symptomen onwaarschijnlijk. Heb je de afgelopen tijd (vooral vlak voordat de spontane reboots begonnen) iets veranderd in de configuratie? Security updates goed bijgehouden?

[ Voor 68% gewijzigd door deadinspace op 18-06-2003 14:35 ]

[cdgrit]

deadinspace schreef op 18 June 2003 @ 14:28:
Heb je de afgelopen tijd (vooral vlak voordat de spontane reboots begonnen) iets veranderd in de configuratie? Security updates goed bijgehouden?

Ongeveer 2 weken voordat het begon heb ik Apache 2.0.46 en PHP 4.3.2 geïnstalleerd. Daarna niets meer veranderd. Heeft dus nog 2 weken perfect gedraaid dus daar zal het niet aan liggen denk ik. Daarna niets meer ge-update dus ook geen security updates (Als die er waren).
If it ain't broke then don't fix it dus niets gewijzigd verder...

[oRc]

Heb ook een keer zoiets gehad en toen zat de fan van mijn proc vol stof, en koeldie hij dus niet goed

[DeMoN]

Ja idd, kan van alles zijn.

Als het een server is en hij is toch al een paar keer gereboot zou het ook geen kwaad kunnen om hem een uurtje down te brengen.

Vervolgens alle fans uitblazen en er gewoon een nieuwe verse voeding in mikken.
Ik denk dat je dan al een grote kans hebt dat het weer werkt

m.a.w. Gewoon een goede onderhoudsbeurt geven

[ Voor 8% gewijzigd door DeMoN op 18-06-2003 16:52 ]

[Wilke]

NOS FAQ: random Crashes stukje al gelezen?

Check daar vooral ook de links naar de PMG "Hangen en opstartproblemen guide" en de Linux Hardwary Stability guides, en draai memtest86 eens. Kortom, de FAQ noemt al een hele lijst dingen die je zou kunnen doen, waarvan niet blijkt dat je ze al hebt geprobeerd

P.S. Gezien de symptomen zet ik eigenlijk ook in op iets met de hardware. Spontaan rebooten ligt zelden aan software, of je bak moet gehacked zijn. chkrootkit zou je evt. kunnen draaien. Kun je een linux kernel compilen? Als gcc daarop segfault, weet je vrijwel 100% zeker dat je hardware stuk is (HD, Mem, CPU, iets anders).

[cdgrit]

Heeft ook nog iemand een idee waarom de tijd vanzelf +/- 8 uur vooruit wordt gezet??

[Verwijderd]

Ja. Waarschijnlijk heb je de 'Linux' klok niet op 'local' tijd staan maar op US tijd met de PC klok op GMT.

Of zoiets..
Ik bedoel dus synchen met een Internet (atoom) klok.
Maar ehh 8 uur vooruit zou een Japanse klok zijn??

De boel loopt vast -> de interne klok wordt niet meer goed teruggezet.

[ Voor 27% gewijzigd door Verwijderd op 19-06-2003 16:51 ]

[cdgrit]

Het zal wel een hardwareprobleem geweest zijn, want de HD zit nu tijdelijk in een ander systeem en nu draait het al een paar dagen probleemloos. Eerder rebootte hij soms wel 3 keer per dag dus zal wel brakke hardware zijn geweest...

[Wilke]

En als je nu probeert om dingen als memtest86 e.d. te draaien, dan kom je er misschien ook nog achter waar het hardware-probleem zit!

[LollieStick]

Ik vermoed ook dat het je geheugen is. Ik wil niet meteen zeggen dat het kapot is. Het kunnen ook te agressieve timings zijn.

De 8 uur tijdverschil is typisch een software probleem. Dat is niet echt een defecte hardware probleem, tenzij de bak al 10 jaar oud is of de baterij ontploft is

Bekijk je software configuratie m.b.t. de klok even en draai memtest even. Tenzij je geld teveel hebt en gewoon een andere bak als server aanstelt

Wilke schreef op 18 June 2003 @ 21:40:
Kun je een linux kernel compilen? Als gcc daarop segfault, weet je vrijwel 100% zeker dat je hardware stuk is (HD, Mem, CPU, iets anders)

Het is goed dat je vrijwel er bij zet Het kan namelijk ook een bug in de kernelsource zijn. Ik heb al vaker gehad dat de kernel met speciale features voor een bepaalde bak niet wou compilen terwijl hij op dezelfde bak hij een kernel voor mijn eigen systeem wel wou compilen.

Of dat dus een goeie test is betwijfel ik. Zoals ik hierboven al aangeef denk ik dat de timings op het geheugen te agressief ingesteld zijn of dat het geheugen gewoon brak is. Als ik de topicstarter was zou ik het BIOS op fail-safe instellingen zetten en dan memtest86 te draaien.

[ Voor 50% gewijzigd door LollieStick op 24-06-2003 00:59 ]

[deadinspace]

LinuxUser schreef op 24 juni 2003 @ 00:52:
Het is goed dat je vrijwel er bij zet Het kan namelijk ook een bug in de kernelsource zijn. Ik heb al vaker gehad dat de kernel met speciale features voor een bepaalde bak niet wou compilen terwijl hij op dezelfde bak hij een kernel voor mijn eigen systeem wel wou compilen.

Maar Wilke had het niet over "niet compilen", hij had het over het segven van gcc. Als gcc segvt, dan lukt het compilen natuurlijk ook niet, maar als gcc (een productie versie iig) segvt dan moet je toch eventjes kritisch naar je hardware gaan kijken

[cdgrit]

LinuxUser schreef op 24 juni 2003 @ 00:52:
Ik vermoed ook dat het je geheugen is. Ik wil niet meteen zeggen dat het kapot is. Het kunnen ook te agressieve timings zijn.

Het geheugen reepje is nu bijna 3 maand oud (nieuw dus ) en heeft 2 maand met de huidige settings uitstekend gedraaid. Kan het daar dan nog wel aan liggen? Dat dat nu ineens problemen gaat geven?

[Whizzer]

heb je nu al memtest gedraaid??? die kan het je vertellen hoor....

[Verwijderd]

deadinspace schreef op 24 June 2003 @ 01:07:
[...]

*knip*
, maar als gcc (een productie versie iig) segvt dan moet je toch eventjes kritisch naar je hardware gaan kijken

deadinspace->
Waar kun je eigenlijk Segmentatie fouten door krijgen ?

Hier vraag ik het mij af, omdat het meestal bij verkeerde versies en foute links schijnt te komen op mijn warrige RH9 systeem.

Zover ik begrijp is het een corruptie van de pointer naar het volgende (gelinkte) geheugen blok. En als een routine naar een blok code in een ander bestand (lib of executable) verwijst dat niet wordt gevonden, krijg je de segmentatie fout.
(Ehh ik dan meestal, hier op mijn systeem.)

Of zie ik het (weer eens ) helemaal fout..?

PS Nog even nadenkend, als het een hardware geheugenfout is, treedt de corruptie op in die pomter zelf, omdat het geheugen daar een fout heeft gemaakt denk ik..

[ Voor 10% gewijzigd door Verwijderd op 24-06-2003 13:41 ]

[Wilke]

cdgrit schreef op 24 June 2003 @ 08:59:
[...]

Het geheugen reepje[..]Kan het daar dan nog wel aan liggen? Dat dat nu ineens problemen gaat geven?

Ik tel in deze draad nu 6 keer het woord 'memtest'. Ook in de FAQ wordt dit al genoemd. Als je niets wil proberen en gewoon verder blijft vragen naar andere dingen zonder iets te proberen, gaat je probleem waarschijnlijk niet opgelost worden....

Idem voor de suggesties die deadinspace en LinuxUser al noemen.

@Hooi: Segmentation faults zijn hetzelfde als in Windows de "General Protection Faillure's". Het betekent dat een programma geheugen probeert te lezen of schrijven waar hij niet bij mag. Meestal wijst dit op een programmeerfout, maar het kan ook gebeuren doordat je hardware kapot is - als je geheugen ineens een andere pointer bevat, dan is de kans heel groot dat 'ie ineens wijst naar geheugen waar het programma dat het geheugen gebruikt niet bij mag. Vandaar dat je van kapot geheugen i.h.a. meer segfaults krijgt dan 'normaal'.

Bij het compileren van een standaard Linux-kernel met een stabiele GCC zou dit normaal nooit moeten gebeuren. Vandaar dat bv. Tom's Hardware Guide het ook regelmatig gebruikt als een van de tests om te zien of een systeem wel stabiel draait (en hoe lang 'ie er over doet natuurlijk ).

Needless to ask: je systeem is toch niet overgeklokt he!?