verdwenen process gijzelt tcp poort

[thunder7]

Ik heb een server, windows 2003 (32-bit, up-to-date m.b.t. updates van microsoft).

Daarop draait een koppeling, die luistert op een bepaalde poort en daarop via tcp connecties aanneemt. Die koppeling is een proces en heeft ook een service.

Nu is windows nogal in de war; het proces is weg, en ook weer niet.

In tasklist of pslist of de task manager is het proces niet zichtbaar.

in netstat staan er nog een aantal verbindingen met deze poort open; sommige op ESTABLISHED, andere op CLOSE_WAIT. In tcpview van www.sysinternals.com staat in de kolom 'process' bij de poorten '<non-existent>:16160' waarbij 16160 het pid van het proces is.
Dat kan ik niet killen:

taskkill /f /t pid 16160
ERROR: The process "16160" not found.

Ik weet dat een reboot de problemen op zou lossen, maar ik wil geen reboot; het is een productie-server. Ik wil gewoon die poort weer vrij hebben zodat ik de koppeling opnieuw op kan starten.

Iemand enig idee? Google bood niet echt veel hulp, en het is lastig om een specifieke zoekopdracht te bedenken.

[pennenlikker]

Probeer dit programma eens.
En je zou eens moeten denken om je structuur van je servers anders in te gaan richten, als je een server echt niet mag of kan herstarten doe je iets fout.
Dat is gewoon wachten op problemen imho.

[thunder7]

pennenlikker schreef op maandag 12 januari 2009 @ 12:38:
Probeer dit programma eens.
En je zou eens moeten denken om je structuur van je servers anders in te gaan richten, als je een server echt niet mag of kan herstarten doe je iets fout.
Dat is gewoon wachten op problemen imho.

Ik kan hem wel herstarten, maar diverse timeouts en niet helemaa cluster-proof database software zorgen ervoor dat dat gauw zo'n 15 minuten duurt, en als het SAN een slechte bui heeft (lees: niet op wil komen op de andere server) duurt het nog langer. Vroeger, toen we onder unix een uptime van 500 dagen gemakkelijk haalden, was ik ook niet gewend om voor een weigerachtige koppeling de server te moeten herstarten. Daar kun je met lsof, fuser, de /proc interface etc. een proces dat je kwijt wil, tenminste ook echt afschieten.
Het is toch eigenlijk diep triest dat een windows-server waar een herstart problematisch is gelijk 'wachten op problemen' heet...

Ook met cports blijft er één of ander proces aan staan; ik kan het niet afsluiten. Hij geeft ook geen foutmelding (typisch windows).

Bedankt!

[pennenlikker]

Nou dat was eigenlijk niet op basis van het os eigenlijk, meer op bijvoorbeeld falende hardware.
Ook in redundant uitgevoerde servers kan het goed fout gaan, dan maakt het ook niet meer uit welk os je hebt en dan moet de server down.
Als veel mensen dan afhankelijk zijn van die server dan staan ze allemaal kokend bij je bureau.
Maar ik snap jou positie, een reboot kan maar alleen in uiterste nood.

[elevator]

thunder7 schreef op maandag 12 januari 2009 @ 14:38:
Ook met cports blijft er één of ander proces aan staan; ik kan het niet afsluiten. Hij geeft ook geen foutmelding (typisch windows).

Windows geeft over het algemeen vrij goede meldingen is mijn ervaring.

Kan je met ProcessExplorer niet de handle naar de TCP/IP poort sluiten?

[thunder7]

In de lijst met processen in Process Explorer kwam het proces niet voor. Uiteindelijk heb ik de server dan toch maar gereboot. Het schijnt er nu eenmaal bij te horen.

[joopv]

Jaja, de ultieme fout tolerantie: men heeft de *gebruiker* tolerant gemaakt voor fouten.

[ Voor 9% gewijzigd door joopv op 13-01-2009 19:35 ]