Hvordan frigiver jeg en port

Aner det ikke, men har du prøvet at genstarte netværket?

sudo invoke-rc.d networking restart

Den bryder sig sikkert ikke om det ;-)

bruger@mint-11 ~ $ sudo invoke-rc.d networking restart
* Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces
* Reconfiguring network interfaces... [ OK ]
bruger@mint-11 ~ $

Ved ikke om det kan bruges.

To close a port, you can use the following command as root:

fuser -k 80/tcp

Which will close port 80 (used by the web server).

http://tuxarena.blogspot.com/2009/01/tip-of-day-close-port-in-linux.html

You could alternatively use iptables:

iptables -I INPUT -p tcp -dport 80 -j DROP
It basically accomplishes what you want.

http://superuser.com/questions/127863/manually-closing-a-port-from-comm…

os.

Ingen af forslagene virker, desværre....

@0

Dette link beskriver et ligende problem.

http://www.linuxquestions.org/questions/programming-9/python-programs-d…

Er det en proxy du selv har skrevet og må man se koden ?

/The Stig

release en port? lige så snart dit program stopper med at lytte på det skal porten da være fri igen?

#0
Hvilket system sidder du med?

Såvidt jeg husker var der et problem med tidligere kernels, at de var længe om at frigive porte, jeg er rimelig sikker på at jeg kæmpede med det dengang jeg stadig brugte aMule.

#4: Er det en proxy du selv har skrevet og må man se koden ?

Det er munchy: http://proxies.xhaus.com/python/munchy.html

Det problem du henviser til er noget anderledes da det mere handler om at proxien ikke genbruger porten.

#5: release en port? lige så snart dit program stopper med at lytte på det skal porten da være fri igen?

Nu er det sådan at proxien kører indtil man afbryder den med Ctrl-C. Jeg har også prøvet en kill -9 for at se om det skulle gøre nogen forskel. Det gør det ikke, i alle tilfælde er outputtet:

Traceback (most recent call last):
File "./munchy.py", line 445, in
ProxyServer(PORT).serve_forever()
File "./munchy.py", line 436, in __init__
ServerBase.__init__(self, ('', port), ProxyHandler)
File "/usr/lib/python2.6/SocketServer.py", line 402, in __init__
self.server_bind()
File "/usr/lib/python2.6/SocketServer.py", line 413, in server_bind
self.socket.bind(self.server_address)
File "", line 1, in bind
socket.error: [Errno 98] Address already in use


Efter et stykke tid fungerer det igen.

#6: Hvilket system sidder du med?

LMDE, så det skulle være rimeligt uptodate.

@marlar
Jeg har prøvet koden du linker til og den frigiver fint porten på en fedora 16, med denne python version:

python.x86_64 2.7.2-5.2.fc16

når jeg bruger ctrl-c, jeg kan starte den igen lige efter den giver promten tilbage. Det kunne godt tyde på noget 2.6 specifikt problem du har.

http://stackoverflow.com/questions/2765152/what-is-the-correct-way-to-c… (jeg ved så ikke om dette link kan være til hjælp).

/The Stig

#8:

Jeg prøvede at indsætte linjen fra linket uden at det dog hjalp. Men måske er det noget 2.6 halløj, vil prøve med 2.7 senere.

@marlar

Min test var ikke helt gennemført, da jeg bare startede programmet og killede programmet igen uden, at havde være forbundet til det, for så at starte det igen, hvilket ikke gav nogen fejl.

Hvis jeg derimod starter programmet og telnet'er til det på port 8000 og prøver at afbryde programmet, siger den
"KeyboardInterrupt", når jeg I min telnet session, skriver get , hvilket så selvfølgeligt giver mig en bad request 400 i min telnet session, hvilket også var forventligt.

Breaker jeg så programmet - med ctrl-c og starter det igen, så kommer denne fejl, som du jo kender så godt :D socket.error: [Errno 98] Address already in use

Så er det jo lige man tænker, hvorfor skal man så lige vente 60 sec, for at den lukker porten?

hvis du i en anden terminal kører en "netstat -a -n | grep 8000" lige efter du break'er ud med ctrl-c, så skulle du gerne se en linie ligende dette:

tcp 0 0 127.0.0.1:8000 127.0.0.1:49202 TIME_WAIT

TIME_WAIT tænker man så - and why 60 sec ?

Men det er der også en forklaring på, den lange forklaring ligger i denne rfc

http://www.elook.org/computing/rfc/rfc1337.txt

og den korte er, at hvis man lukker og starter en port, så kan der faktisk være nogle pakker, som ikke er nået frem i den gammle session og hermed rammer den nye session og lukker den nye forbindelse igen. Det det handler om, er at server og klient skal have tid til at lukke forbindelsen pænt.

Man kan selvfølgeligt godt tweake på dette, men det er default linux OS network operation, at man skal vente 60 sec.

Håber det er forklaring nok og jeg ikke har fået dig til at jagte skygger med 2.6 vs 2.7 python.

/The Stig

#10

Tak for den meget grundige forklaring. Det sætter jeg stor pris på. Det er sådanne indlæg der gør det værd at kommer her på forummet :)

Håber det er forklaring nok og jeg ikke har fået dig til at jagte skygger med 2.6 vs 2.7 python.

Jeg har ikke nået at kigge nærmere på 2.7 så det er helt ok.