[C++/Unix] Chiusura socket

[Fede_Reghe]

Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare 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.

Esiste un comando linux o qualche riga C++ che mi permette di chiudere il socket zombie del programma chiuso?

[vizzz]

Originariamente inviato da Fede_Reghe

Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare 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.

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.

[71104]

bello Linux, bel sistema

[Fede_Reghe]

Originariamente inviato da vizzz

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?

[gepeppe]

Originariamente inviato da 71104

bello Linux, bel sistema

ma come sei monotono...inoltre un post che non serve a nulla (come questo rigo, ma almeno dopo ho scritto altro )

Originariamente inviato da Fede_Reghe

Ho un programma C++ che apre un socket in listen e fa tutto quello che deve fare 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.
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 , in modo che si connetta di nuovo ad un indirizzo "già in uso" e cosi la bind non ti da più problemi.

EDIT:

Originariamente inviato da Fede_Reghe

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.

[71104]

Originariamente inviato da gepeppe

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"

edit - anzi, al contrario del "sistema di mamma M$"

[gepeppe]

hai cambiato l'avatar apposta??

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]

Grazie a tutti! Gestendo i segnali, e chiudendo la socket, it's all ok!

[71104]

Originariamente inviato da gepeppe

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...

[gepeppe]

Originariamente inviato da 71104

ennò bello mio, c'è problema e problema: che un processo possa causare un leak a livello di sistema mi pare abbastanza scandaloso...

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...
(non posso farti l'esempio dei socket su winzoz perchè non sò come funzionano li )

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...

[Albi89]

Originariamente inviato da gepeppe

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...

Sono proprio curioso di vedere come questo sarebbe possibile in Windows Vista

[gepeppe]

Originariamente inviato da Albi89

Sono proprio curioso di vedere come questo sarebbe possibile in Windows Vista

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

[71104]

Originariamente inviato da gepeppe

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...

cheeee????
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

se hai paura di riuscirci (lol ) fallo su una macchina virtuale.

(non posso farti l'esempio dei socket su winzoz perchè non sò come funzionano li )

quasi identici purtroppo

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

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...

[Albi89]

Originariamente inviato da gepeppe

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...

[71104]

Originariamente inviato da Albi89

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++

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.

[gepeppe]

Originariamente inviato da 71104

cheeee????
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

se hai paura di riuscirci (lol ) 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

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...

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

[gepeppe]

Originariamente inviato da 71104

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++

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?

[eVuGEGA]

Originariamente inviato da 71104

cheeee????
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

se hai paura di riuscirci (lol ) fallo su una macchina virtuale.

Originariamente inviato da gepeppe

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]

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.

[MD.TPTM]

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".