View Full Version : [C++/Unix] Chiusura socket
Fede_Reghe
22-06-2008, 11:48
Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare :D Il problema nasce quando devo riavviarlo, gli invio un kill SIGTERM da shell di linux e se tento di riavviarlo ho l'errore "BIND FAILED", come se la porta fosse ancora occupata. L'unico modo è attendere una decina di minuti o riavviare il sistema. :mbe:
Esiste un comando linux o qualche riga C++ che mi permette di chiudere il socket zombie del programma chiuso?
Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare :D Il problema nasce quando devo riavviarlo, gli invio un kill SIGTERM da shell di linux e se tento di riavviarlo ho l'errore "BIND FAILED", come se la porta fosse ancora occupata. L'unico modo è attendere una decina di minuti o riavviare il sistema. :mbe:
Esiste un comando linux o qualche riga C++ che mi permette di chiudere il socket zombie del programma chiuso?
potresti gestire il segnale SIGTERM nel tuo programma e forzare la chiusura del socket.
bello Linux, bel sistema :asd:
Fede_Reghe
22-06-2008, 12:00
potresti gestire il segnale SIGTERM nel tuo programma e forzare la chiusura del socket.
googlando ho trovato che posso utilizzare la funzione
signal(SIGTERM, funzione);
Ma precisamente, dove va messa? nel main() all'inizio del programma?
bello Linux, bel sistema :asd:
ma come sei monotono...inoltre un post che non serve a nulla (come questo rigo, ma almeno dopo ho scritto altro :p )
Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare :D Il problema nasce quando devo riavviarlo, gli invio un kill SIGTERM da shell di linux e se tento di riavviarlo ho l'errore "BIND FAILED", come se la porta fosse ancora occupata. L'unico modo è attendere una decina di minuti o riavviare il sistema. :mbe:
Esiste un comando linux o qualche riga C++ che mi permette di chiudere il socket zombie del programma chiuso?
Se ho ccapito bene, per risolvere dovresti cambiare un'opzione del socket, è giusto un rigo di codice, ma non lo dicordo :D, in modo che si connetta di nuovo ad un indirizzo "già in uso" e cosi la bind non ti da più problemi.
EDIT:
googlando ho trovato che posso utilizzare la funzione
signal(SIGTERM, funzione);
Ma precisamente, dove va messa? nel main() all'inizio del programma?
la devi mettere nel main...all'inizio. Poi ti crei la funzione "funzione" e li dentro chiudi il socket.
ma come sei monotono... abbi pazienza, ma da sempre il mondo è popolato da contaballe che me lo rifilano come il sistema più sicuro del mondo che "non permette ai processi di prendersi tutte le risorse che vogliono", "al contrario di Windows" :asd:
edit - anzi, al contrario del "sistema di mamma M$" :Puke:
hai cambiato l'avatar apposta?? :D
cmq ognuno la pensa come vuole...c'è chi preferisce windows, virus, antivirus, anti questo e quello..chi ama linux coi problemoni irrisolvibili delle socket....ma a me non interessa (e cmq in questa discussione non c'entra nulla)
Solo è inutile dire "bello linux", quando Fede_Reghe ha chiesto tutta un altra cosa...e come se andassi nella sezione di windows e per ogni problema che qualcuno posta, io scrivessi "bello windows"....
Fede_Reghe
22-06-2008, 12:24
Grazie a tutti! Gestendo i segnali, e chiudendo la socket, it's all ok! :D
e come se andassi nella sezione di windows e per ogni problema che qualcuno posta, io scrivessi "bello windows".... ennò bello mio, c'è problema e problema: che un processo possa causare un leak a livello di sistema mi pare abbastanza scandaloso... :D
ennò bello mio, c'è problema e problema: che un processo possa causare un leak a livello di sistema mi pare abbastanza scandaloso... :D
ennò bello mio, c'è problema e problema: che un processo possa da solo cancellare l'intero sistema, compresa la cartella di windows e il suo registro, senza restrizioni mi pare abbastanza scandaloso... :D
(non posso farti l'esempio dei socket su winzoz perchè non sò come funzionano li :D)
cmq se avesse inserito la gestione dei segnali oppure l'opzione sulla socket, questo problema non si avrebbe avuto...Inoltre il suo problema è che, quando riavvia il programma (credo sia il client ma il discorso è sempre lo stesso), la porta che usa risulta ancora occupata. Per questo la bind ritorna errore....non c'è nessun problema di memoria...anzi.
sullo Stevens o gapil se ne parla...
ennò bello mio, c'è problema e problema: che un processo possa da solo cancellare l'intero sistema, compresa la cartella di windows e il suo registro, senza restrizioni mi pare abbastanza scandaloso... :D
Sono proprio curioso di vedere come questo sarebbe possibile in Windows Vista :fagiano:
Sono proprio curioso di vedere come questo sarebbe possibile in Windows Vista :fagiano:
non lo è?
è stato inserito una sorta di "root"?? Se è cosi sono contento..finalmente dove 8 versioni di windows hanno fatto una cosa utile....cmq spiegami, sono curioso :)
ennò bello mio, c'è problema e problema: che un processo possa da solo cancellare l'intero sistema, compresa la cartella di windows e il suo registro, senza restrizioni mi pare abbastanza scandaloso... :D cheeee???? :rotfl:
guarda, pure da Windows XP (lasciando perdere account amministrativi vs. LUA e menate varie), apri esplora risorse e dimmi se riesci a cancellare ntoskrnl.exe :D
se hai paura di riuscirci (lol :asd: ) fallo su una macchina virtuale.
(non posso farti l'esempio dei socket su winzoz perchè non sò come funzionano li :D) quasi identici purtroppo :mc:
cmq se avesse inserito la gestione dei segnali oppure l'opzione sulla socket, questo problema non si avrebbe avuto... un po' come il multitasking cooperativo di Windows 3.1: concediamo la CPU al processo di turno e fidiamoci che la restituisca :rolleyes:
Inoltre il suo problema è che, quando riavvia il programma (credo sia il client ma il discorso è sempre lo stesso), la porta che usa risulta ancora occupata. Per questo la bind ritorna errore....non c'è nessun problema di memoria...anzi. dici? e se io scrivo un programma idiotissimo che con un for apre tutte e 65535 le porte e lo termino brutalmente? il problema non è tanto di memoria... :D
non lo è?
è stato inserito una sorta di "root"?? Se è cosi sono contento..finalmente dove 8 versioni di windows hanno fatto una cosa utile....cmq spiegami, sono curioso :)
Sì qualcosa di simile, anche se non ti saprei dire i dettagli con precisione.
In ogni caso anche quando si è loggati con un account che ha privilegi di amministratore, è necessario confermare ogni operazione su file che non si trovano nelle cartella Utente dell'utente in questione (un po' come la tua home in Linux).
E' molto, molto difficile che qualcosa riesca a farti danni seri senza che tu gli dica esplicitamente "puoi farlo".
D'altra parte, non è che l'utente neofita medio di Ubuntu si faccia troppi problemi a scrivere sudo, quindi la componente di rischio è circa equivalente.
Anche per questo molto software vetusto è incompatibile con win vista, dato che cerca di scrivere file di configurazione e dati direttamente nella cartella programmi, cosa che nn possono fare se non lanciati con espliciti permessi.
Che poi io appoggi win vista e il mio giudizio possa essere di parte non c'è dubbio. Fattostà che, lentezza di avvio a parte, è il sistema più vicino alle mie esigenze che abbia provato.
Ma è anche vero che la lentezza d'avvio è dovuta al fatto che non riesco a resistere all'orologio e al calendario sulla sidebar, e allo sfondo con le foto delle vacanze, e alle finestrelle trasparenti... :O
Sì qualcosa di simile, anche se non ti saprei dire i dettagli con precisione. non è stato "introdotto" nulla di simile: il sistema di sicurezza al 90% c'era già ed era già molto più flessibile di quello di Linux; ciò che è stato introdotto sono nuove features come le etichette di integrità e l'ormai arcinoto UAC.
In ogni caso anche quando si è loggati con un account che ha privilegi di amministratore, è necessario confermare ogni operazione su file che non si trovano nelle cartella Utente dell'utente in questione (un po' come la tua home in Linux). non è detto: le operazioni che richiedono permessi elevati potrebbero venir negate direttamente e senza la presentazione di alcun messaggio di conferma all'utente. tale comportamento dipende da come è scritto il manifest dell'applicazione, sempre che ne abbia uno visto che c'è ancora gente che programma col MinGW in Dev-C++ :asd:
E' molto, molto difficile che qualcosa riesca a farti danni seri senza che tu gli dica esplicitamente "puoi farlo".
D'altra parte, non è che l'utente neofita medio di Ubuntu si faccia troppi problemi a scrivere sudo, quindi la componente di rischio è circa equivalente. anzi: su Windows l'unico utente che di default ha il permesso di logon è SYSTEM.
cheeee???? :rotfl:
guarda, pure da Windows XP (lasciando perdere account amministrativi vs. LUA e menate varie), apri esplora risorse e dimmi se riesci a cancellare ntoskrnl.exe :D
se hai paura di riuscirci (lol :asd: ) fallo su una macchina virtuale.
beh...essendo il file in esecuzione non lo cancella..ma cancella il resto...poi riavvia (perchè windows alla minima cosa devi riavviare) e vedi cosa ti trovi. E poi un virus potrebbe fare questo e molti altri danni. E non mi risulta che virus NON hanno causato il blocco del sistema...anzi riescono a fare quello che vogliono...sbaglio?
Se non avessi un antivirus, il pc lo dovrei formattare dopo 30 secondi (provato)...con un antivirus stò più o meno apposto, ma il pc non rende allo stesso modo (almeno quelli che non usano gli ultimi pc)
un po' come il multitasking cooperativo di Windows 3.1: concediamo la CPU al processo di turno e fidiamoci che la restituisca :rolleyes:
dici? e se io scrivo un programma idiotissimo che con un for apre tutte e 65535 le porte e lo termino brutalmente? il problema non è tanto di memoria... :D
Quelle occupate dal sistema non te le fa aprire, apri le altre...chiudile di botto....e quindi? l'unico problema che puoi avere e che un programma collegato a quelle porte ti dice che il socket ha chiuso la comunicazione...
Scusa ma se io sono un server e stò in attesa di client...a questo punto se ne connettono 100, attraverso 100 porte diverse (giusto per dire). poi chiudo il server, i client riceveranno il messaggio che il socket è stato chiuso (dalle relative funzioni di lettura e scrittura sul socket). dove stà il problema? Mi sembra un comportamento normale....O chiudi il server di botto o stacchi il acvo di rete, tutto questo grave problema non lo vedo
non è stato "introdotto" nulla di simile: il sistema di sicurezza al 90% c'era già ed era già molto più flessibile di quello di Linux; ciò che è stato introdotto sono nuove features come le etichette di integrità e l'ormai arcinoto UAC.
non è detto: le operazioni che richiedono permessi elevati potrebbero venir negate direttamente e senza la presentazione di alcun messaggio di conferma all'utente. tale comportamento dipende da come è scritto il manifest dell'applicazione, sempre che ne abbia uno visto che c'è ancora gente che programma col MinGW in Dev-C++ :asd:
anzi: su Windows l'unico utente che di default ha il permesso di logon è SYSTEM.
e come mai allora progammi tipo cclener oppure reg qualcosa riescono a modificare il registro di windows??
Se è come dici, certi programmi non potrebbero venire eseguiti..ma ci sono moltissime guide della serie "come ripulire il registro di windows"....se fosse un'operazione di super-utente questo non sarebbe possibile...eppure lo era
Se il registro viene compromesso windows e i programmi diventano inutilizzabili....no?
cheeee???? :rotfl:
guarda, pure da Windows XP (lasciando perdere account amministrativi vs. LUA e menate varie), apri esplora risorse e dimmi se riesci a cancellare ntoskrnl.exe :D
se hai paura di riuscirci (lol :asd: ) fallo su una macchina virtuale.
beh...essendo il file in esecuzione non lo cancella..
In realta' ntoskrnl.exe non viene cancellato perche' e' protetto dal Windows File Protection (che puo essere disabilitato abbasanza facilmente se si e' loggati come amministratore), non perche' e' in uso
Questo almeno fino ad XP, Vista non so
cdimauro
22-06-2008, 17:00
gepeppe, lascia perdere: Windows ha sistemi di sicurezza notevoli già a partire da NT. E t'ho detto tutto.
Continuate la discussione sui socket, che è meglio. ;)
Rassicuro 71104 che il socket TCP "fantasma" che rimane aperto dopo un'interruzione improvvisa di un processo che aveva effettuato una bind viene chiuso dal kernel poco dopo. Mi sembra strano che Fede_Reghe debba aspettare anche 10 minuti, a me spesso capita che sia riutilizzabile sin da subito, o in caso di bind error al massimo aspetto 60 secondi. In ogni caso per evitare l'errore si può utilizzare l'opzione del socket "SO_REUSEADDR".
tomminno
23-06-2008, 08:33
Scusa ma se io sono un server e stò in attesa di client...a questo punto se ne connettono 100, attraverso 100 porte diverse (giusto per dire). poi chiudo il server, i client riceveranno il messaggio che il socket è stato chiuso (dalle relative funzioni di lettura e scrittura sul socket). dove stà il problema? Mi sembra un comportamento normale....O chiudi il server di botto o stacchi il acvo di rete, tutto questo grave problema non lo vedo
Quando un processo viene chiuso tutte le risorse da questo occupate devono ritornare al sistema, non solo la memoria.
Come fai a non vederci niente di strano?
tomminno
23-06-2008, 08:36
e come mai allora progammi tipo cclener oppure reg qualcosa riescono a modificare il registro di windows??
Perchè eseguiti con account amministratore?
Prova da root ae eseguire rm -r e poi ne riparliamo.
Se il registro viene compromesso windows e i programmi diventano inutilizzabili....no?
Questo è vero.
Nel registro esiste anche l'associazione degli eseguibili, cioè modificando una voce di registro puoi non far riconoscere più gli eseguibili a windows, che al doppio click ti chiederà con quale programma aprirli!
ilsensine
23-06-2008, 09:54
Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare :D Il problema nasce quando devo riavviarlo, gli invio un kill SIGTERM da shell di linux e se tento di riavviarlo ho l'errore "BIND FAILED", come se la porta fosse ancora occupata. L'unico modo è attendere una decina di minuti o riavviare il sistema. :mbe:
Ci sono ancora alcune operazioni pendenti da effettuare sul socket (come gestire la finalizzazione di una richiesta, ecc.). Non c'è nessun leak, l'inode verrà rilasciato appena possibile. netstat -avntp ti fornisce i dettagli sullo stato di finalizzazione.
Se per te è un problema, setsockopt con SO_REUSEADDR come ti hanno consigliato e sparisce il problema. V. man setsockopt.
<...>
Sei incommentabile
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.