Comment mettre fin à une connexion TCP établie par bash lui-même?

J'ai utilisé exec 3<>/dev/tcp/192.168.0.101/6435pour établir une connexion TCP avec 192.168.0.101:6435. Et j'ai reçu et envoyé quelques messages avec la pipecommande.

Maintenant, je veux mettre fin à la connexion TCP. Mais, avec ss -anpetje peux voir que bash lui-même détient cette connexion, sans bifurquer un processus enfant.

J'ai essayé d'envoyer les signaux 9 et 15 au processus bash, mais comme vous le savez, bash ne peut pas se tuer.

Alors, puis-je mettre fin à la connexion TCP que j'ai établie sans mettre fin aux pts que j'utilise (ni la tuer par root ni envoyer Ctrl + D)?

— TJM
source

Pourriez-vous obtenir un autre obus et tuer bashavec cet obus?

— trysis

bashpeut certainement se tuer - bien que ce ne soit pas vraiment ce que vous voulez faire ici!

— psmears

@TJM pour rendre cette question fascinante plus utile aux autres, pourriez-vous développer la pipecommande que vous utilisez et que je ne trouve pas sur mon système? De quel paquet pipevient-il? Quels (exemple) paramètres pouvez-vous lui transmettre pour envoyer / recevoir des données via la /dev/tcp/...connexion? Merci.

— arielf

@arielf Typiquement, je suis un débutant en informatique, et j'ai trouvé ce genre d'utilisation à partir d'un script shell bash appelé sedbot, vous pouvez le trouver sur Github. Oui, je ne trouve aucun fichier /dev/tcp, même je ne le trouve pas /dev/tcp. Mais, il semble que vous puissiez envoyer / recevoir des données avec pipece type de fichiers. On dit qu'il est utilisé /dev/tcp/ip/portpour les connexions tcp et /dev/udp/ip/portpour les packages udp. Car mon anglais n'est pas très bon, je ne sais pas comment l'expliquer correctement. N'hésitez pas à modifier la question et à poster une réponse.

— TJM

@TJM merci. La question portait sur la pipecommande que vous mentionnez. J'ai regardé https://github.com/clsr/sedbot/blob/master/sedbot.bash. Il n'y a pas de pipecommande là-bas. Il définit deux fonctions: readmsget sendmsglire / écrire depuis / vers la connexion respectivement. readmsgutilise IFS= read -r -u 3 -t "$READ_TIMEOUT" linepour lire du descripteur de fichier 3 dans la variable lineet sendmsgutilise echo "$(date +%s.%N) >>> $line" >&4pour écrire dans le descripteur de fichier 4. Quoi qu'il en soit, cela clarifie la méthode complète. La pipemention " commande" reste encore un mystère pour les lecteurs.

— arielf

Cette commande a ouvert la connexion sur le descripteur de fichier 3. Donc, pour fermer la connexion, vous devez fermer le descripteur de fichier 3. Pour ce faire:

exec 3<&-

— Patrick
source

Est-ce que cela fera un bon shutdown(3)appel, ou tout simplement close(2)le descripteur de fichier?

— Kevin

Fait un close, mais shutdownn'est pas plus approprié que proche. shutdownLa seule utilisation réelle est lorsque vous ne souhaitez fermer qu'un côté d'une prise duplex.

— Patrick

A shutdownenvoie un FIN, tandis que a closeenvoie un RST. Ce sont des choses matériellement différentes.

— Kevin

@Kevin RST est provoqué par la fermeture du socket sans en lire d'abord toutes les données. Si vous lisez jusqu'à la fin des données puis effectuez une fermeture, la fermeture enverra un FIN.

— kasperd

@kasperd: Dans l'API de socket UNIX, la seule façon de savoir s'il y a des données en attente est d'essayer de lire à partir d'un socket non bloquant, ou d'appeler quelque chose comme select(), et je ne pense pas que bash propose l'une ou l'autre option.

— Kevin