Effectivement Ph Husson, il faut que je scrute tous les PID de /proc pour retrouver mes petits. Je voulais éviter de passer par ce genre de méthode, mais bon s'il n'y a pas d'autre solution...
Il est globalement (sauf cas rare ou le serveur informe de son PID) impossible de dériver le PID d'un service depuis une connexion reseau externe. Pour plusieurs raison, la premiere etant que c'est inutile, la seconde que cela sera OS dependant alors que TCP/IP n'a pas pour but de l'etre, et la troisieme (que je vois) est quel PID le service te donnerai ? celui du listener ? celui du fork qui est a ton ecoute ? a l'ecoute d'une autre session TCP ?
Bref ca peut pas se faire via reseau.
Deuxiemement cela ne peut pas se faire autrement qu'en inspectant les tambouilles interne de l'OS hote car il n'existe pas non plus d'appel systeme permettant a un process de demander les fichiers (sous unix tout est fichier) ouverts par un autre process et generalement cela veut dire: application non portable et application root uniquement.
Quant à votre solution, deneb, elle est intéressante mais ne correpsond pas au but que je me suis fixé. J'ai vraiment besoin de connaître l'application en cause. L'idée dans un premier temps serait de faire un lecteur fenêtré qui afficherait tous les logiciels qui ouvrent un port en TCP/UDP sur la station de travail.
xterm -e 'sudo watch netstat -taupe' ?
Enfin, liberforce, je cherche à être indépendant de tout logiciel. Le plus simple pour moi serait d'utiliser la sortie de netstat -ltaupe par exemple, mais ca implique l'installation de netstat. Je souhaite faire un soft qui n'a besoin que de lui-même.
Oui en meme temps c'est comme cela que le bordel avance, passer son temps a faire et refaire les meme outils, meme pour apprendre est a mon avis une perte de temps et faire des gros outils tout en un complement contraire a la philosophie d'un unix.
C'est pas pour rien que les shells sont extremement utiles: c'est grace a la centaine de petits outils que nous pouvons interfacer ensembles (sort, uniq, cat, sed, perl (oui bon), awk, tail, grep, find & co).
Deuxieme chose comme dit plus haut acceder a toutes les entrees de /proc necessite forcement les droits admins, et passer une application UI (user interface) en full root c'est generalement une tres mauvaise idée.
P.S. : Une question me vient à écrivant ces quelques lignes. Le répertoire /proc dépend de la configuration du noyau il me semble. Existe-t-il des systèmes linux/Unix dépourvus de cette fonctionnalité ?
Reponse donnée plus haut: pour faire simple le /proc n'est pas normé c'est d'ailleurs pour cela qu'il existe des outils comme ps, lsof netstat, top & co qui eux ont des comportement un peu plus stables.
Il est peu probable qu'un analyseur de /proc linux fonctionne sous BSD et encore moins sous solaris.
[^] # Re: merci
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au message Fonctions de recherche réseau. Évalué à 2.
Il est globalement (sauf cas rare ou le serveur informe de son PID) impossible de dériver le PID d'un service depuis une connexion reseau externe. Pour plusieurs raison, la premiere etant que c'est inutile, la seconde que cela sera OS dependant alors que TCP/IP n'a pas pour but de l'etre, et la troisieme (que je vois) est quel PID le service te donnerai ? celui du listener ? celui du fork qui est a ton ecoute ? a l'ecoute d'une autre session TCP ?
Bref ca peut pas se faire via reseau.
Deuxiemement cela ne peut pas se faire autrement qu'en inspectant les tambouilles interne de l'OS hote car il n'existe pas non plus d'appel systeme permettant a un process de demander les fichiers (sous unix tout est fichier) ouverts par un autre process et generalement cela veut dire: application non portable et application root uniquement.
Quant à votre solution, deneb, elle est intéressante mais ne correpsond pas au but que je me suis fixé. J'ai vraiment besoin de connaître l'application en cause. L'idée dans un premier temps serait de faire un lecteur fenêtré qui afficherait tous les logiciels qui ouvrent un port en TCP/UDP sur la station de travail.
xterm -e 'sudo watch netstat -taupe' ?
Enfin, liberforce, je cherche à être indépendant de tout logiciel. Le plus simple pour moi serait d'utiliser la sortie de netstat -ltaupe par exemple, mais ca implique l'installation de netstat. Je souhaite faire un soft qui n'a besoin que de lui-même.
Oui en meme temps c'est comme cela que le bordel avance, passer son temps a faire et refaire les meme outils, meme pour apprendre est a mon avis une perte de temps et faire des gros outils tout en un complement contraire a la philosophie d'un unix.
C'est pas pour rien que les shells sont extremement utiles: c'est grace a la centaine de petits outils que nous pouvons interfacer ensembles (sort, uniq, cat, sed, perl (oui bon), awk, tail, grep, find & co).
Deuxieme chose comme dit plus haut acceder a toutes les entrees de /proc necessite forcement les droits admins, et passer une application UI (user interface) en full root c'est generalement une tres mauvaise idée.
P.S. : Une question me vient à écrivant ces quelques lignes. Le répertoire /proc dépend de la configuration du noyau il me semble. Existe-t-il des systèmes linux/Unix dépourvus de cette fonctionnalité ?
Reponse donnée plus haut: pour faire simple le /proc n'est pas normé c'est d'ailleurs pour cela qu'il existe des outils comme ps, lsof netstat, top & co qui eux ont des comportement un peu plus stables.
Il est peu probable qu'un analyseur de /proc linux fonctionne sous BSD et encore moins sous solaris.