[Ubuntu 8.10] Xinetd zombie poorten?

[DieterVDW]

Hallo,

Op onze servers draaien wij 2 services via xinetd, op poort 9100 en 9200.
Als alles goed draait dan krijgt ik het volgende te zien als ik netstat uitvoer:

code:

root@server:~# netstat -A inet -lpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
...
tcp        0      0 127.0.0.1:9100          0.0.0.0:*               LISTEN      18716/xinetd
tcp        0      0 0.0.0.0:9200            0.0.0.0:*               LISTEN      18716/xinetd
...

Op 1 server gebeurt het echter soms dat deze services stoppen met werken.
Dan zie ik het volgende:

code:

root@server:~# netstat -A inet -lpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
...
tcp        0      0 127.0.0.1:9100          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:9200            0.0.0.0:*               LISTEN      -
...

De poorten zijn dus niet meer gebonden aan een proces?
Ik kan nog steeds connecten met deze poorten, maar krijg geen reactie.

Als ik xinetd stop, dan blijven deze poorten gewoon bestaan. Ik kan de services niet meer starten, want xinetd klaagt dat de poorten al in gebruik zijn en dat 'm niet kan binden.

code:

Feb 24 13:49:03 server xinetd[9548]: bind failed (Address already in use (errno = 98)). service = bla
Feb 24 13:49:03 server xinetd[9548]: Service bla failed to start and is deactivated.

Hoe is dit mogelijk?
Hoe kan ik die poorten sluiten?

De configuratie van de services:

code:

service a
{
        flags           = REUSE
        socket_type     = stream
        port            = 9100
        wait            = no
        user            = bla
        server          = /pad/naar/script
        log_on_failure  += USERID
        disable         = no
        only_from       = 127.0.0.1/32
        bind            = 127.0.0.1
        deny_time       = NEVER
        per_source      = UNLIMITED
        cps             = 1000 0
}

service b
{
        flags           = REUSE
        socket_type     = stream
        port            = 9200
        wait            = no
        user            = nobody
        server          = /pad/naar/ander/script
        log_on_failure  += USERID
        disable         = no
        only_from       = 0.0.0.0/0
}

Wat gegevens over de machine:

code:

root@server:~# uname -a
Linux server 2.6.16-xenU #1 SMP Mon May 28 03:41:49 SAST 2007 i686 GNU/Linux
root@server:~# dpkg --list | grep xinetd
ii  xinetd                               1:2.3.14-7ubuntu1             replacement for inetd with many enhancements

Edit:
Ondertussen al gevonden dat het xinted process een sigfault gaf, waardoor het proces verdween maar de sockets achterbleven. Oorzaak: buggy kernel.

Mijn vraag blijft echter geldig: hoe geraak je van deze sockets af zonder te rebooten?
Het lijkt niet alsof ze timeouten of zo. Die procesloze sockets zijn nu zeker al 2,5u aanwezig op die machine...

[ Voor 6% gewijzigd door DieterVDW op 24-02-2010 16:51 ]

[Siebz0r]

Ik zou toch een andere kernel proberen
Je hebt waarschijnlijk nu 2,5u of meer een server die niet functioneel is, een kernel recompilen en rebooten duurt nooit zo lang.

[DieterVDW]

Yep ondertussen al geswitchd naar nieuwere versie van kernel. De server is gelukkig maar 1 van de enkele in een loadbalanced opstelling. Is gelukkig dus niet zo erg als er 1tje uitvalt...

Maar het moet toch mogelijk zijn om die sockets te verwijderen als het proces al beëindigd is zonder de machine te herstarten ...

[Siebz0r]

Heeft xinetd geen force parameter?

De verklaring van de openstaande poorten is volgens mij:
-start proces
-open poorten
-proces laadt in het geheugen + poorten
-proces crasht, poorten verliezen hun aansturing (blijven open zonder proces, maar in het geheugen)

Dan zou je het geheugen op moeten kunnen schonen, of een applicatie geforceerd op die poort moeten runnen, toch?

[DieterVDW]

Siebz0r schreef op donderdag 25 februari 2010 @ 08:43:
Heeft xinetd geen force parameter?

Geen force parameter op xinetd voor zover ik zie...

Siebz0r schreef op donderdag 25 februari 2010 @ 08:43:
Dan zou je het geheugen op moeten kunnen schonen, of een applicatie geforceerd op die poort moeten runnen, toch?

Dat denk ik ook, maar hoe...?

[Siebz0r]

sshd op zo'n poort runnen?
Het is maar een hersenspinsel, dus weet niet of het kan / of het zo opgelost kan worden etc.

[DieterVDW]

Siebz0r schreef op donderdag 25 februari 2010 @ 11:57:
sshd op zo'n poort runnen?
Het is maar een hersenspinsel, dus weet niet of het kan / of het zo opgelost kan worden etc.

Denk dat die ook gewoon zal klagen dat de poort al in gebruik is?

[The-Hi_End]

al eens geprobeerd met fuser?

fuser 9100/tcp om te kijken welk proces er nog gebruik maakt van deze poort, fuser -k 9100/tcp om het process te killen.

wel uitvoeren als root, anders lukt het niet

[DieterVDW]

The-Hi_End schreef op donderdag 25 februari 2010 @ 15:24:
al eens geprobeerd met fuser?

fuser 9100/tcp om te kijken welk proces er nog gebruik maakt van deze poort, fuser -k 9100/tcp om het process te killen.

wel uitvoeren als root, anders lukt het niet

Yep fuser had ik geprobeerd, maar gaf ook niks op die poort.
fuser -k heb ik wel niet geprobeerd. Als fuser echter geen PID kan genereren, zal 'm allicht ook niks kunnen killen?

[The-Hi_End]

stukje uit de man page:

The -k option only works on processes. If the user is the kernel, fuser will print an advice, but take no action beyond that.

dus ik zou zeggen: probeer het eens.

wat geeft het volgende commando weer voor de betreffende poorten als het probleem zich voor doet?

code:

lsof -i -n -P