Remote Slack 9 box dood, maar toch ook niet helemaal...

[Verwijderd]

Tis een vreemd probleem wat ik heb en ik weet ook niet of iemand het herkent.

Ik heb dus een Slack 9.0 box (P200/45mb), kernel 2.4.19, 2 ReiserFS partities (/ en /home==>encrypted met loop-AES). Iptables support had ik volgens mij in de kernel gebakken en Shorewall is wat ik gebruik als script.

Hier had ik pureftpd, SSH en icecast op draaien (normaal ook ircd, maar vanwege crashes maar even niet).
Dit werkte ogenschijnlijk allemaal prima.

Vorige week woensdag rond 16:00 leek de machine plotseling te zijn gecrashed na 5-6 dagen uptime, maar ik kon nog wel telnetten naar poorten waarop de verschillende services luisterden. Normaal gesproken zie je dan ook nog een outputstring van zo'n service (bijv. SSH-1.99-OpenSSH_3.5p1), maar in dit geval ontbrak die. Met gecrashed bedoel ik trouwens het onbereikbaar zijn van SSH (via Putty), FTP en audiostream (Icecast). Pings worden gedropped.

Machine weer gereboot toen en ong. 4 dagen lang burnP5 en burnMMX uit het cpuburn pakket gedraaid, bovenop de bovengenoemde diensten (zie ook README uit het pakket voor beschrijving cpuburn). Geen centje pijn, machine kon het wel behappen. Zo kon ik met enige zekerheid de hardware als oorzaak elimineren.

Ook vandaag weer na ong. 5-6 dagen lijkt de machine dood, maar lukt het nog wel om te telnetten naar de luisterende poorten:

code:

user@loekie:~/Appz$ telnet remotebox 22
Trying xxx.xx.xxx.xx...
Connected to remotebox.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

Ditzelfde resultaat ook met pureftpd poorten en icecast poort.

Aangezien ik niet fysiek bij de machine in de buurt ben probeer ik langs deze weg een diagnose te stellen.

Als mogelijke oorzaak dacht ik aan Shorewall (oftewel iptables) die misschien gecrashed zou zijn (als dat uberhaupt mogelijk is).

Iemand verder enig idee?

[PowerSp00n]

Begin eens met het doorlezen van verschillende logs? En dan vooral rond de tijd dat de bak niet meer te bereiken is.

[Verwijderd]

Dit probleem heb ik ook gehad. In feite crashed userland (je services) maar blijft de ip stack nog gewoon functioneren (waardoor je wel een connectie kunt establishen). Probeer als eerste eens je kernel te upgraden.

[ Voor 4% gewijzigd door Verwijderd op 05-11-2003 13:31 ]

[Wilke]

Ja, volgens mij zijn daar zelfs firewall-distrootjes op gebaseerd, om in runlevel 0 (normaalgesproken dus 'uit') nog een complete firewall te laten draaien. Dus het kan inderdaad om totaal geen filesystems, processen (!) of wat dan ook meer te hebben, maar toch een werkende IP stack met firewall te hebben. Redelijk onhackbaar.

Alleen een config veranderen is er dan niet bij, en loggen e.d. ook niet natuurlijk

[Verwijderd]

offtopic:
Wilke: Uit m'n hoofd was het iemand van sysadminmag die daar bij toeval op kwam. Hij halte z'n systeem, en merkte vervolgens dat die box nog steeds packets forwarde. Vervolgens probeerde hij hetzelfde truukje maar dan met een geladen netfilter ruleset, en ook dat werke. Echter is dat wat anders dan dat hier bedoeld word, denk ik.... Stoer is het echter wel

[Verwijderd]

Ik ben nu r3boot's advies aan het opvolgen: nieuwe kernel versie 2.4.22. Machine moet stabiel zijn, dus ik waag me liever niet aan dev kernels

Ik kon vanochtend nog telnetten naar poorten op de machine, maar dat lukte rond 13:00 ook niet meer.

In de logfiles waren trouwens geen bruikbare clues te vinden wat de oorzaak evt. zou kunnen verduidelijken. Het loggen stopte gewoon rond 15:30 gisteren, terwijl ik dus tot vandaag nog kon telnetten op verschillende poorten...

Vreemd probleem blijft het dus waarvan ik hoop dat deze na de kernelupgrade niet meer optreedt.

Bedankt voor de insights tot nu toe

[deadinspace]

Verwijderd schreef op 05 november 2003 @ 13:30:
In feite crashed userland (je services) maar blijft de ip stack nog gewoon functioneren (waardoor je wel een connectie kunt establishen).

Dat klopt niet helemaal... Als de userspace processes sterven, dan sluit de kernel automatisch de filedescriptors van die processes, en daarmee dus ook de poorten die ze open hadden.

Ik herken het symptoom echter wel, van systemen waar de HD (of SCSI/IDE bus) ermee ophield. Het systeem leeft dan in principe nog wel, maar alles dat bij je HD wil moet oneindig lang wachten. Een connectie op eenbepaalde poort kan dus wel geaccepteerd worden, maar als de daemon iets van HD nodig heeft (denk ook aan uitgeswapte pages), dan duurt het oneindig lang voor de daemon iets nuttigs terug kan zeggen.

Verschijnt er iets nuttigs op de console van die machine?

[Verwijderd]

Deadinspace, je zou best eens gelijk kunnen hebben *slik*

Ik had ff badblocks gedraaid op de bewuste bak: output hieruit was dus een aantal sectoren....

Ondertussen heb ik de HD in een ouwe Compaq Deskpro 2000 (P166/32M) geplaatst, nieuwe 2.4.22 kernel en hij draait nu dus net:

code:

 08:39:54 up 18 min,  1 user,  load average: 0.01, 0.05, 0.02

Ik hoop dat ie et nog wel ff volhoudt

[Verwijderd]

Nou tis nu ong. 23:20 en m'n box ligt weer op z'n gat - wederom alleen de halve telnetsessies op de poorten die nog enige reacties geven.

Andere machine (Compaq), andere kernel => zelfde resultaat, dus helaas denk ik (mede door uitkomst badblocks) dat deadinspace het bij het rechte eind had: HD kaput...

/me wordt er maar moe van....

[ Voor 6% gewijzigd door Verwijderd op 12-11-2003 23:23 ]

[deadinspace]

Als je nou kijkt of er wat op de console verschijnt... Als de kernel niet bij de HD kan, dan zal hij daar wel over klagen

[Verwijderd]

deadinspace schreef op 12 november 2003 @ 23:45:
Als je nou kijkt of er wat op de console verschijnt... Als de kernel niet bij de HD kan, dan zal hij daar wel over klagen

No can't do, heb alleen remote ssh xs... Moet helemaal naar A'dam tuffen om er fysiek bij te kunnen.
Helaas zie je in de logs niks terug van evt. kernel meldingen over de slechte bereikbaarheid van de hd. Aan de andere kant is dit uiteraard ook weer vrij logisch met logfiles die naar de hd moeten worden weggeschreven

Ik ga nu een andere hd erin pleuren waarop ik Slack ff preinstall. Kom ik er meteen achter of het de hele tijd de hd was of niet.

[deadinspace]

Tip: als je nog een bak hebt: gebruik seriele console, dan kun je dergelijke dingen zien zonder een monitor (of videokaart) nodig te hebben

[Verwijderd]

deadinspace schreef op 13 november 2003 @ 14:42:
Tip: als je nog een bak hebt: gebruik seriele console, dan kun je dergelijke dingen zien zonder een monitor (of videokaart) nodig te hebben

Hmmm... dit is nieuw terrein voor mij

Soort null modem verbinding oid?

Aah wacht: Google and Search are my friends

[ Voor 8% gewijzigd door Verwijderd op 14-11-2003 13:43 ]

[ge-flopt]

het stukje van deadinspace ( deadinspace in "Remote Slack 9 box dood, maar toch ook n..." ) deed even een belletje bij me rinkelen. Heb je toch geen power management aan staan. Heb dit ook gehad met mijn ssh sessies. Gingen de hdd uit (in stand by) dan kon ik mijn server niet meer enaderen. MAW draaien je hdd's nog op volle toeren?

[NuKeFaCe]

Verwijderd schreef op 05 november 2003 @ 13:30:
Dit probleem heb ik ook gehad. In feite crashed userland (je services) maar blijft de ip stack nog gewoon functioneren (waardoor je wel een connectie kunt establishen). Probeer als eerste eens je kernel te upgraden.

Ah dat was ut dus ... ik had ook het probleem dat na 1/2 dagen m'n http en andere service's niet meer te berijken waren .... en ik heb toen idd m'n kernel geupdate naar 2.4.x (als ik het goed heb) en nergens meer last van gehad(ik draai ook iptables)

[ Voor 3% gewijzigd door NuKeFaCe op 14-11-2003 13:51 ]