Comment forcer la fermeture du socket sur Linux?

Pour cette raison, je veux essayer quelque chose de nouveau – fermez le socket en utilisant un appel système.

La situation en deux mots – impossible de définir le délai de requête de la bibliothèque mysql (l’API C, reportez-vous au lien pour plus d’informations), je souhaite donc essayer de fermer le socket pour voir comment la bibliothèque réagira. Ce n’est probablement pas une bonne idée, mais je veux quand même l’essayer.

Voici ce que j’ai fait – il y a un autre fil commencé – un minuteur. Donc, après un délai d’attente spécifique (disons 10 secondes), s’il n’y a pas de réponse, je veux fermer le socket. La structure MYSQL a membre net , qui est également une structure, et détient le fd . Mais quand j’essaie de faire ça:

 shutdown( m_pOwner->m_ptrDBConnection->m_mysql.net.fd, SHUT_RDWR ); close( m_pOwner->m_ptrDBConnection->m_mysql.net.fd ); 

Rien ne se passe. Les valeurs renvoyées par shutdown et close sont 0 , mais le socket est toujours ouvert (car après 60 secondes d’attente, la firebase database renvoie un résultat, ce qui signifie que le client mysql attend toujours une réponse de la firebase database.

Des idées?

Merci

EDIT – Oui, il y a une transaction en cours pendant que j’essaie de fermer le socket. Mais c’est là le problème – je ne peux ni mettre fin à la requête, ni fermer la connexion, rien, et je ne veux pas attendre tout le délai d’attente, qui est de 20 minutes et 30 secondes, ou quelque chose du genre. C’est pourquoi je cherche une force brute ..: /

Juste un coup dans le noir, mais assurez-vous d’annuler / terminer toutes les transactions en cours. Je ne connais pas bien l’API MySQL C, mais j’imagine qu’il existe un moyen de vérifier s’il existe des connexions / requêtes actives. Vous ne pourrez peut-être pas fermer le socket simplement parce que des choses sont toujours en cours d’exécution et qu’elles doivent être amenées à un état “résolu”, que ce soit commis ou annulé. Je commencerais par là et verrais ce qui se passe. Vous ne voulez vraiment pas arrêter le style de “force brute” du socket si vous avez quelque chose en suspens car vos données ne seraient pas dans un “état” fiable par la suite – vous ne sauriez pas quelles transactions ont abouti ou non, bien que J’imagine que MySQL annulerait toutes les transactions en attente si la connexion échouait brutalement.

EDIT : D’après ce que j’ai trouvé dans Googling “MySQL stopping runaway runaway”, le consensus semble être de demander à MySQL de mettre fin au fil de la requête en mode runaway / long en utilisant

 KILL thread-id 

J’imagine que l’ID de thread est disponible pour vous dans la structure de données MySQL qui contient le socket. Vous voudrez peut-être essayer ceci, bien que l’IIRC ait besoin de privilèges super-utilisateurs.

EDIT # 2 : Apparemment, MySQL fournit un mécanisme de sécurité qui redémarrera une connexion fermée. Par conséquent, le fait de forcer la fermeture du socket ne mettra pas fin à la requête. Une fois que vous l’avez fermée, MySQL en ouvrira une autre et tentera de compléter la requête. Désactiver cette option vous permettra de fermer le socket et de terminer la requête.

Les commentaires ci-dessous montrent comment la réponse a été trouvée et le processus de reflection impliqué.

Il semble que vous renconsortingez un problème avec le temporisateur d’attente TCP, ce qui signifie qu’il se fermera éventuellement. [Longue histoire] c’est en quelque sorte inévitable. Il y a eu une autre discussion à ce sujet.

fermer vs socket d’arrêt?

Autant que je sache, si shutdown() et close() renvoient tous deux 0, il ne fait aucun doute que vous avez correctement fermé un socket. Le fait est que vous auriez pu fermer le mauvais fd. Ou bien le serveur ne pouvait pas réagir correctement à un arrêt correct (dans ce cas, cela pourrait être considéré comme un bogue du serveur: aucune raison d’attendre quand même que des données soient reçues). Je continuerais à chercher un moyen de le faire.