Server loopt continue vast

[Verwijderd]

Sinds gisteren loopt m'n server continue vast.

eerste keer: vrijdag op zaterdagnacht
Tweede keer: zaterdag rond 18:00 uur
Derde keer: zaterdag op zondagnacht

Het opvallende is dat dit continue gebeurd als ik weg ben.
Ik heb express nadat ik gisteren uitgelogd was van SSH nog even gekeken of alles draaide en dat was prima. Daarna mn pc thuis uitgezet en gaan slapen. Vanochtend bleek die weer vastgelopen.

Natuurlijk heel irritant voor een server. In /var/log/messages staat niks. uit boot.log kan ik ook niks wijzer worden. Iemand die weet hoe ik er kan achterkomen wat het probleem is?

[Verwijderd]

Kijk eens of alle ventilators nog draaien, misschien word hij te warm waardoor hij vastslaagt

[Verwijderd]

Verwijderd schreef op zondag 26 december 2004 @ 09:54:
Kijk eens of alle ventilators nog draaien, misschien word hij te warm waardoor hij vastslaagt

Dat wordt dan een probleem. Het is een dedicated bak .

Ik heb de server al wel een paar dagen langer en toen had ik er geen last van. Daarna is er qwa hardware niks veranderd en het is allemaal nieuw spul is me verteld dus lijkt me niet een al te grote kans....

[Verwijderd]

De kans bestaat altijd dat er een ventilator het begeven heeft, zoals die van de voeding misschien, dan word de voeding te warm en zal hij ook wel afslagen, of de cpu fan, cpu word te warm en slaagt dicht, andere fan --> systeem word te warm --> slaagt dicht

[Verwijderd]

Maar is er niet eerst iets dat ik dingen op de server zelf kan nakijken. Wellicht dat er gewoon iets van software zorgt voor t vastlopen. Denk dat ik dat beter eerst even kan nakijken voor ik mensen naar het datacenter stuur...

Overigens ben ik er gisteren achter gekomen dat reboots ook zn werk niet doen.

Hij blijft tijdens het afsluiten ergens op hangen. Hij blijft ook reageren op ping maar alles (mail/http/ftp etc.) is down. Pas als ik m via de APC een harde reboot geef komt die weer online.....

[jurri@n]

Staat er misschien een proces in je cron dat iedere nacht iets uitvoert waardoor de boel vastloopt?

Draai eens een nachtje zonder dat de cron draait...

Verder ga ik (en anderen waarschijnlijk ook) er van uit dat je software up-to-date is...

[ Voor 23% gewijzigd door jurri@n op 26-12-2004 10:07 ]

[Super_ik]

ik zou je geheugen maar eens controleren, met memtest86 ofzo.

FAQ Non-Windows Operating Systems - update: 08/04/2004

[ Voor 37% gewijzigd door Super_ik op 26-12-2004 10:10 ]

[Verwijderd]

Er staan cronjobs in die elke nacht uitgevoerd worden.
Maar als ik die gewoon ingeef (dus los van de cronjob) is er geen enkel probleem.

Hij is vanacht rond 04:00 uur "vastgelopen"/offline gegaan.
Dit is wat ik kan vinden in /var/log/messages:

Dec 26 04:02:06 wouter syslogd 1.4.1: restart.
Dec 26 09:45:46 wouter syslogd 1.4.1: restart.

Uiteraard is alle software up2date.

//edit

Dit is trouwens mn crontab:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
00 2 * * * /usr/bin/freshclam --quiet -l /var/log/clamav/clam-update.log
00 3 * * * /var/qmail/bin/qmailstats 1>/dev/null 2>/dev/null

[ Voor 38% gewijzigd door Verwijderd op 26-12-2004 10:16 ]

[Super_ik]

dan zou ik toch maar eens je hardware na gaan lopen op defecten

[Verwijderd]

mij lijkt het een geheugen kwestie. memtest draaien.... fouten? whoppa garantie claimen...

zelf heb ik ook wel eens iets vergelijkbaars gehad met een nieuwe hardeschijf.

[Verwijderd]

Wat staat er in je cron.daily. Die wordt namelijk om 4.02 opgestart.

[alt-92]

* alt-92 had een stukkende procfan laatst.

Ding draaide nog wel, maar bleef @ random wel eens steken, en vooral als er jobs liepen die wat meer load veroorzaakten > random hangers dus.

[SvMp]

Ik heb exact hetzelfde gehad en nooit kunnen achterhalen wat er nou aan de hand is. Bij mij gaat het om een Compaq Deskpro pIII 600 server met FreeBSD 4.11.

Niks terug te vinden in de logs, niks opvallends, hardware lijkt prima te zijn.

Maar er gebeurde nog iets: De switch raakte overstuur. Er brandden willekeurige lampjes. Ook een 2e switch die er via uplink aanhangt, voor de computers beneden, was overstuur. Netwerkverkeer tussen computers was niet meer mogelijk, totdat ik de switches beide van de stroom haalde en de server rebootte. Het is mij nooit gelukt of de crash van de switches oorzaak of gevolg zijn van de crash van de server. Ik heb het drie keer achter elkaar dagelijks gehad, daarna hield het ineens op en inmiddels draait die server alweer 50 dagen.

Vraag aan de topicstarter: Hoe zit het bij jou met de switch? Draait deze gewoon netjes door?

[Verwijderd]

Net even een paar uur weggeweest en ja hoor, ik kom terug en hij staat weer vast.
Nu staat er in /var/log/messages:

Dec 26 10:21:40 wouter su(pam_unix)[2442]: session closed for user root
Dec 26 13:47:50 wouter syslogd 1.4.1: restart.

In /etc/cron.daily (is een map) staan deze bestanden/mappen:

[root@wouter cron.daily]# ls -all
total 44
drwxr-xr-x 2 root root 4096 Dec 23 18:16 .
drwxr-xr-x 54 root root 4096 Dec 26 13:52 ..
lrwxrwxrwx 1 root root 28 Dec 23 03:26 00-logwatch -> ../log.d/scripts/logwatch.pl
-rwxr-xr-x 1 root root 418 Nov 18 22:49 00-makewhatis.cron
-rwxr-xr-x 1 root root 276 Feb 15 2004 0anacron
-rwxr-xr-x 1 root root 74 Oct 19 11:52 freshclam
-rwxr-xr-x 1 root root 180 Feb 15 2004 logrotate
-rwxr-xr-x 1 root root 1603 May 5 2004 prelink
-rwxr-xr-x 1 root root 104 Apr 16 2004 rpm
-rwxr-xr-x 1 root root 82 Apr 16 2004 slocate.cron
-rwxr-xr-x 1 root root 193 Feb 15 2004 tmpwatch
-rwxr-xr-x 1 root root 136 May 11 2004 yum.cron

Van de switch heb ik geen idee, aangezien ik deze bak huur (dedicated). Ben dus zelf nooit bij deze server geweest. Wel kan ik nog altijd gewoon de APC (zit dacht ik op dezelfde switch) bereiken. Dus de switch zou er niet uit (blijven) liggen denk ik. Pingen naar de server gaat ook nog gewoon als die vast zit. Alleen niks werkt voor de rest meer (apache, ssh, dns, ftp, mail etc.).

[ Voor 6% gewijzigd door Verwijderd op 26-12-2004 16:59 ]

[Rac-On]

waarom gebruik je niet ff een leuk scriptje op je temps en fanspeed uit te lezen? Doe ik ook constant met mijn server en daardoor ben ik er ook achter gekomen dat er een fan mol was:



Ik gebruik hier mbmon voor, waarvan ik de waardes in MRTG zet om grafieken te laten maken...

(ik heb een redundante cpu fan, dus de stijging in temperatuur (blauwe lijn) is minimaal). Ik kan het perl script wat ik hiervoor gebruik wel voor je posten?

[ Voor 18% gewijzigd door Rac-On op 26-12-2004 14:06 ]

[alt-92]

Daar heb ik anders wel belangstelling voor

[stefklep]

neem Hotsanic even zit alles gelijk in Kan je gelijk alles in de gaate houden cpu mem enz.
Gebruik het zelf ook voor mijn colo bak.
Url: http://hotsanic.sourceforge.net/

[Verwijderd]

Nou er wordt morgen naar de server-hardware gekeken wat er fout kan zijn.
Kreeg steeds meer rare dingen. Qmail weigert dienst, apache veranderd de map /etc/httpd/logs in een bestand en wil daardoor niet meer starten. DNS weigert dienst etc. etc.

Even afwachten dus

[Rac-On]

@Backslash: het graphen van temp en fanspeed doe ik met mrtg en mbmon. Beide kan je, op een Debian bak altans, gewoon apt-getten. Ik heb de volgende configuratie files:

mrtg.cfg

code:

Options[cputemp]: growright, nopercent, gauge, noarrow, nobanner, nolegend,

Target[cputemp] : `/var/www/mrtg/cputemp.pl`
Unscaled[cputemp]: ymwd
Maxbytes[cputemp] : 60
YTics[cputemp]: 4
YticsFactor[cputemp]: 1
Title[cputemp] : Bambi Statistieken
PageTop[cputemp] : <h1> CPU en Case temperatuur statistieken voor Bambi </h1>
YLegend[cputemp] : Temperatuur °C
ShortLegend[cputemp]: °C
Legend1[cputemp]: cputemp
Legend2[cputemp]: cputemp
Legend3[cputemp]: cputemp
Legend4[cputemp]: cputemp
LegendI[cputemp]: &nbsp; Case &nbsp;&nbsp;
LegendO[cputemp]: &nbsp; CPU &nbsp;
Step[cputemp]: 300

En het script cputemp.pl bevat:

code:

#!/usr/bin/perl
use Net::Telnet;
$cputemp =  `sudo mbmon -T 2 -c 1`;
$casetemp = `sudo mbmon -T 1 -c 1`;
$casetemp =~ s/\n//;
$cputemp =~ s/\n//;

$hostname = 'bambi';
$uptime = `awk '{printf "%d",\$1}' /proc/uptime`;
$uptime = $uptime / 86400;
$uptime = int($uptime);
$uptime = "$uptime dagen";
print "$casetemp\n$cputemp\n$uptime\n$hostname";
exit();

Mrtg zal vervolgens het perl script aanroepen wat op beurt weer mbmon aanroept. Omdat mdmon als root moeten draaien, heb ik de volgende regel toegevoegd aan /etc/sudoers:

code:

mrtg    ALL = NOPASSWD:/usr/bin/mbmon

Voor het configureren en meer over mrtg kan je kijken op de site.

[alt-92]

mrtg heb ik, draai Debian op meerdere servers, maar dit was ik nog niet tegengekomen
thanx

[Rac-On]

no problem, geen moeite om het hier ff te posten. Als je hulp nodig hebt, hoor ik het vanzelf wel. Overigens kan je de -T optie van mbmon altijd vervangen door -F voor fanspeed, en je hebt er ook een paar voor voltages.
Zelf heb ik nog een extra functie binnen cputemp om de status ook te monitoren via Big Brother maar ik weet niet of je dat gebruikt?

[[NUT]]

Hey dat is stom toeval ... dat euvel heb ik ook...

Het gebeurde gisteren ochtend voor het laatst, maar voorheen was het vrijwel altijd na 17:00 op vrijdag, ALS het gebeurde ...

Het is mij een raadsel hoe, ik draai een GRsec kernel, met extended logging, en er is echt niets te bespeuren wat de oorzaak zou kunnen zijn ... ik begin inderdaad twijfelen aan de gezondheid van het geheugen of het systeem in het algemeen... alleen zou dat niet verklaren waarom het dan op zulke specefieke tijden gebeurt ... dat is het verdachte er aan: ik werk, en het gebeurt altijd als ik net klaar ben met werken en onderweg naar huis...

[Tomsworld]

rac-on schreef op zondag 26 december 2004 @ 22:16:
@Backslash: het graphen van temp en fanspeed doe ik met mrtg en mbmon. Beide kan je, op een Debian bak altans, gewoon apt-getten. Ik heb de volgende configuratie files:

mrtg.cfg

code:

Options[cputemp]: growright, nopercent, gauge, noarrow, nobanner, nolegend,

Target[cputemp] : `/var/www/mrtg/cputemp.pl`
Unscaled[cputemp]: ymwd
Maxbytes[cputemp] : 60
YTics[cputemp]: 4
YticsFactor[cputemp]: 1
Title[cputemp] : Bambi Statistieken
PageTop[cputemp] : <h1> CPU en Case temperatuur statistieken voor Bambi </h1>
YLegend[cputemp] : Temperatuur °C
ShortLegend[cputemp]: °C
Legend1[cputemp]: cputemp
Legend2[cputemp]: cputemp
Legend3[cputemp]: cputemp
Legend4[cputemp]: cputemp
LegendI[cputemp]: &nbsp; Case &nbsp;&nbsp;
LegendO[cputemp]: &nbsp; CPU &nbsp;
Step[cputemp]: 300

En het script cputemp.pl bevat:

code:

#!/usr/bin/perl
use Net::Telnet;
$cputemp =  `sudo mbmon -T 2 -c 1`;
$casetemp = `sudo mbmon -T 1 -c 1`;
$casetemp =~ s/\n//;
$cputemp =~ s/\n//;

$hostname = 'bambi';
$uptime = `awk '{printf "%d",\$1}' /proc/uptime`;
$uptime = $uptime / 86400;
$uptime = int($uptime);
$uptime = "$uptime dagen";
print "$casetemp\n$cputemp\n$uptime\n$hostname";
exit();

Mrtg zal vervolgens het perl script aanroepen wat op beurt weer mbmon aanroept. Omdat mdmon als root moeten draaien, heb ik de volgende regel toegevoegd aan /etc/sudoers:

code:

mrtg    ALL = NOPASSWD:/usr/bin/mbmon

Voor het configureren en meer over mrtg kan je kijken op de site.

Zeer intressant, wel enkel unstable maar weinig dependencies, echt een vooruitgang dat er zoiets is, ik heb er ook al achter gezocht maar nog niet gevonden.

[Rac-On]

als je een kernel met libsensor support hebt, hoef je geen gebruik te maken van mbmon, maar zul je cputemp.pl wat aan moeten passen.

of je draait net als * Rac-On gewoon Debian unstable

[Verwijderd]

vanochtend liep die weer vast rond 4 uur. Dit stond er dit keer in de error log:

Dec 27 04:02:01 wouter logrotate: ALERT exited abnormally with [1]

Dus ik even gezocht op Google en dat bracht me hier.
Wel raar dat ik daar nog steeds last van heb, als ik de nieuwste versie van ppp gewoon geinstalleerd heb staan....

Maar goed, eerst maar eens afwachten wat die hardware check zometeen gaat opleveren...

[Verwijderd]

Nou vandaag is het geheugen vervangen, scheen niet kapot te zijn maar toch vervangen.
Ook is de IDE kabel van de harde schijf naar het mobo vervangen, scheen wat mis mee te zijn heb ik gehoord. Server heeft vervolgens een frisse installatie van Fedora Core 2 gekregen. Alleen wat updates binnen gehaald (dus niks bijzonders) maar de problemen met vastlopen zijn er nog steeds.

Morgen wordt het moederbord vervangen...

[[NUT]]

je kan ook niets in de kern.log vinden in /var/log/ ? bij mij kon ik APIC errors vinden (hangen samen met SMP, dual proc's dus) maar ook dat het VM processen begon te killen omdat het geheugen vol zit/zat ...

er is bij mij dus duidelijk een lekkend proces, en ben dus opzoek naar de beste manier om die te vinden... iemand suggesties?

[Verwijderd]

Ik heb op m'n hele systeem geen kern.log

Anyway, moederbord is dus vervangen en weer een nieuwe install.
Probleem lijkt bij mij opgelost. D.w.z.: Ik heb alleen alle updates binnen gehaald, wat users/rechten geregeld en de mailserver (qmail) geinstalleerd en de server doet het tot nu toe nu stabiel.

Vanacht even afwachten.

[Verwijderd]

Nou inmiddels de eerste vastloper weer gehad

Ik begin langzamerhand toch de indruk te krijgen dat het softwarematig is.
Alhoewel ik er niks bijzonders op heb staan. Namelijk:

- Alle updates via up2date (update -u).
- Apache, PHP, MySQL, OpenSSH 3.9
- Qmail (installatie van qmailrocks.org)
- ProFTPd

In logs staat ook nog steeds niks bijzonders. Iemand nog een idee?

[SvMp]

Toch die switch checken

[Verwijderd]

Maak eens een image van je server (ghost, dd, partimage, of zo) en zet het eens op een andere test-pc.... dan weet je zeker dat je hardware uit kunt schakelen in de server zelf. Kijk of die het langer volhoudt.

[Verwijderd]

Dat kan ik dus niet, aangezien het een dedicated bak is .
De switch is ook vrijwel zeker niks mee. Anders had ik wel gehoord dat meer mensen er last van hebben. Vanavond wordt de voeding nog vervangen. CPU koeler (en andere koelers) lijken goed te werken. Tempraturen blijven continue stabiel en op nette waardes (CPU blijft bijv. onder de 40 graden).

Even afwachten of de voeding vervangen het probleem op gaat lossen...

[Verwijderd]

Nou inmiddels is dus _alle_ hardware vervangen. OS had tijdens het booten aardig wat probs (waarvan ik er al aardig wat opgelost heb (waar je met een beetje googlen al niet komt )).
Ik wil dat allemaal weg hebben. Want het lijkt me dat het dan toch softwarematig is. De server hangt namelijk nog steeds regelmatig (al lijkt het minder te zijn dan voorheen).

Echter, voor deze error en fails kan ik niks bruikbaars vinden:

Dec 30 10:05:15 wouter kernel: There is already a security framework initialized, register_security failed.
Dec 30 10:05:17 wouter kernel: cdrom: open failed.
Dec 30 16:53:39 wouter kudzu: failed
Dec 30 17:50:18 wouter kernel: 83.149.xxx.xxx sent an invalid ICMP type 3, code 0 error to a broadcast: 83.149.xxx.xxx on eth0

Iemand die me hiermee kan helpen?

[ Voor 13% gewijzigd door Verwijderd op 01-01-2005 00:52 ]

[Nahata]

meschien moet je er is een ander linux distro opzetten? want als het software matig is kan dr wel eens een bug in zitten in die distro

[Verwijderd]

Zolang het probleem niet opgelost is moet je niet te snel oordelen over waar de fout moet zitten zogenaamd. Vaak probeer je door korte trial&error snel een oplossing te vinden. Als dat niet lukt moet je systematisch te werk gaan.En dat is nu noodzakelijk, denk ik.

Misschien slim eens hier een lijstje je plaatsen met wat je nu allemaal gedaan hebt. Is echt alle hardware vervangen? Misschien moet je je nic in een ander slot proberen? Netwerkkabel? Voedingskabel? Zet je bios eens terug naar zijn defaults en stel hem opnieuw (zo simpel mogelijk) in. FC2 is een redelijk betrouwbare distro die niet om de dag moet hangen.

Misschien slim om bepaalde processen eens een tijd uit te zetten. Wellicht cron of gedeeltes daarvan?

[ Voor 10% gewijzigd door Verwijderd op 01-01-2005 10:50 ]

[Verwijderd]

Ja, de hardware is compleet vervangen. Volgens de leverancier heb ik een heel nieuwe server gekregen. Vandaar ook de frisse installatie toen. De oude server had een SiS chipset en een Realtek netwerkkaart. Dat is natuurlijk geen feest. Ik heb nu een Intel chipset op het moederbord en een netwerkkaart met Intel chip.

En de oude server draait nu prima bij hun als "testserver". Zonder enige vastlopers zoals ik heb vernomen. Qwa software heb ik alleen de logs nagekeken en geprobeerd zoveel meldingen met errors en fails op te lossen. Waarvan de bovenstaande nog bestaan. En hij is vanacht weer vastgelopen. Dit was in iedergeval na 4:07 vanacht. Dat is de laatste melding in de log (niks bijzonders, dat een ftp sessie werdt gesloten).

Ik denk dus als ik bovenstaande problemen heb opgelost dat het opgelost moet zijn. Iets anders kan het eigenlijk niet zijn....

[geforce5_guy]

Kan het niet zijn dat er spanning schommelingen zijn op je netstroom ? Ik weet niet of een pc daarook voor gevoelig is.

[Verwijderd]

Je bedoeld dat de stroom opeens uitvalt? Nee, dat is uitgesloten.
Als die vastgelopen is antwoord die namelijk nog wel steeds op pings.

Ook is het weleens zo dat als ik 'm een reboot geef via de APC dat die even offline gaat (lees: niet meer reageer op pings) en dan weer online komt en dus weer reageert op pings maar dan gelijk weer lijkt vast te lopen. Apache, proftpd, mysql, openssh etc. komen dan allemaal niet online. Een 2e reboot via de APC biedt dan meestal wel uitkomst (en anders de 3e, 4e enz. ).

Maar het lijkt mij toch eerst dat ik beter eerst alle software problemen kan oplossen en als het dan nog niet opgelost is dat ik dan pas weer naar de hardware ga kijken....

[Swerfer]

Vraag of ze de dedicated bak in een andere kast/ruimte kunnen plaatsen waar hij op een andere switch zit, en op een andere ups zit.

Nadeel is dan wel dat je natuurlijk een ander ip adres krijgt, maar dan kan je wel alle 'externe' factoren uitsluiten...

[Verwijderd]

Precies.... gelijk doen! Als ie dan nog hangt, pas dan kun je echt hardrware uitsluiten.

In de tussentijd zou ik cron uitzetten en helemaal nalopen en tijdelijk uitdunnen.

[Verwijderd]

Dat zal dan toch pas maandag kunnen.
En ik zou gewoon graag even alle software problemen oplossen. Als het daar aan ligt hoeft die maandag ook niet van kast te veranderen.

Ik heb net een reboot gedaan en nu krijg ik nog:

Jan 1 15:21:39 wouter kernel: There is already a security framework initialized, register_security failed.
Jan 1 15:21:39 wouter kernel: Failure registering capabilities with the kernel
Jan 1 15:21:41 wouter kernel: cdrom: open failed.

De error met kudzu is opeens verdwenen...

Iemand die me kan helpen bovenstaande problemen op te lossen???
Dit wil ik echt eerst doen voor ik naar hardware ga kijken.

[stefklep]

Verwijderd schreef op zaterdag 01 januari 2005 @ 15:27:
Dat zal dan toch pas maandag kunnen.
En ik zou gewoon graag even alle software problemen oplossen. Als het daar aan ligt hoeft die maandag ook niet van kast te veranderen.

Ik heb net een reboot gedaan en nu krijg ik nog:


[...]


De error met kudzu is opeens verdwenen...

Iemand die me kan helpen bovenstaande problemen op te lossen???
Dit wil ik echt eerst doen voor ik naar hardware ga kijken.

Gaf hij deze fouten ok al voor toen jij er niks mee had gedaan om zo maar even te zeggen of ging het fout toen jij er mee begon te speelen ? Mischien eens vragen voor een ander OS ?

[ Voor 8% gewijzigd door stefklep op 01-01-2005 21:34 ]

[Verwijderd]

> Jan 1 15:21:39 wouter kernel: There is already a security framework initialized, register_security failed.
Jan 1 15:21:39 wouter kernel: Failure registering capabilities with the kernel

Dit komt denk ik vanwege selinux in FC2 die hier niet geconfigged is. Niet erg denk ik; gewoon een melding.

> Jan 1 15:21:41 wouter kernel: cdrom: open failed.

Lijkt erop alsof een file cdrom geopend moet worden. Waarom weet ik niet, maar ook dit lijkt me niet erg.

Geen aanwijzingen voor het laten hangen van de server.

Nogmaals.... kijk eens naar de automatische processen die er draaien. Cron, e.d. Kijk ook eens naar de statistieken van je netwerkkaart; ifconfig -a.... geen onnodige errors?