Forum Programmation.c Killer un processus sans fermer la socket ?

Posté par str000mff le 12 janvier 2007 à 11:27.

Étiquettes : aucune

jan.

2007

Salut à tous. Dans le cadre d'une reproduction d'incident je tente de flooder un serveur avec des mauvaise deconnection. Donc pour se faire j'ai un process maitre qui creer des fils - qui se connectent donc, et puis au bout d'un certain tps le maitre fait un kill des process avec le signal SIGKILL. Le probleme c'est qu'en tuant ses processus fils, les socket sont fermées proprement et c'est ce que j'aimerais éviter. Quelqu'un a t il une idee ?

Ci dessous ma fonction work qui pourra certainement vous aider à comprendre mon pb...



static int Work(int argc, char **argv)


{


    char host[1024];


    char port[1024];


    char outfile[1024];


    int pid[50] ;


    int nbCreatedProc = 0 ;


    int pidScan = 0 ;


    int flags;


    int fd ;


    SOCKET sock_in ;


    





    memset(host,0,1024);strcpy(host, argv[1]);


    memset(port,0,1024);strcpy(port, argv[2]);


    if (argc>=4)


	tester_trace=atoi(argv[3]);   





    while (1) {


	pid[nbCreatedProc] = fork();


	if (pid[nbCreatedProc] == -1) {  /* Error */	    


	    fprintf(stdout, "proc creation error");


	    return -1 ;


	}


	else if (pid[nbCreatedProc]) {  /* This process */


	    fprintf(stdout, "created proc : %d\n", pid[nbCreatedProc]);


	    nbCreatedProc ++ ;


	    if (nbCreatedProc == 50){


		fprintf(stdout, "50 process created... sleep 2\n");


		sleep(2);


		for (pidScan=0; pidScan < 50 ; pidScan++){


		    kill(pid[pidScan], SIGKILL);


		    fprintf(stdout, "killed proc : %d\n", pid[pidScan]);


		    nbCreatedProc -- ;


		}


	    }


	} else {  /* Child */


	    /*


	     * Open standard streams.


	     */


	    memset(outfile, 0, 1024);


	    sprintf(outfile,"./%d_out.txt",getpid());   	    


	    	   


	    open("/dev/null", O_RDONLY);





	    flags = (O_CREAT | O_WRONLY);


	    flags |= (FLAGS & PROC_TRUNCATE_STDOUT) ? O_TRUNC : O_APPEND;





	    fd=open(outfile, flags, 0666);





	    if (fd >= 0)


		/*redefine stdout*/


		dup2(fd,1);





	    if (client (host, port) < 0) {


		fprintf(stdout, "[%d] CONNECTION FAILED", getpid());


		return -1 ;


	    }


	    else 


		sleep(10);	    


	}


    }

# malpropre !

Posté par daggett le 12 janvier 2007 à 14:52. Évalué à 3.

Le noyau va s'occuper de nettoyer tout ce qui était attaché aux process que tu tues; Pour forcer le noyau à ne pas être propre, du plus simple au plus compliqué (je ne sais pas quelle méthode marchera dans ton cas):

- envoyer un signal "STOP" au lieu de "KILL" à tes process, pour arreter le flux "applicatif"; la connection TCP restera gérée au niveau noyau cependant, bien que silencieuse.
- Debrancher la prise réseau à la main pour simuler le crash de ton client vis-à-vis du serveur distant
- ou alors descendre l'interface réseau pour interdire au noyau d'émettre, ça devrait revenir au même.
- Si tu travailles via réseau, ça peut être embettant :) donc il te faudra créer une deuxieme interface réseau virtuelle du style eth0:0 (dans un network/routage qui soit bien distinct, pour qu'elle ne puisse pas servir de route de secour aux connections de ton appli de test)
- Si tu n'as besoin que de faire des "connect" TCP qui ne soient pas suivis d'une déconnexion, et qu'il n'y a pas de données à réellement envoyer, tu peux tenter d'apprendre à forger des paquets TCP au niveau utilisateur au lieu de laisser faire le kernel. Mais ça c'est si tu es desespéré.
- [^] # Re: malpropre !
  
  Posté par Obsidian le 12 janvier 2007 à 16:37. Évalué à 4.
  
  Le must, à mon avis : on laisse les processus en vie et on fait une règle iptable qui va bien avec un -j DROP de circonstance pour faire disparaître les paquets ciblés dans un accident malencontreux.
  - [^] # Re: malpropre !
    
    Posté par str000mff le 12 janvier 2007 à 16:50. Évalué à 1.
    
    oui, j'y ai pensé, mais ce test est aussi la pour charger le serveur autant que possible. Mon probleme est le suivant : bloquer uniquement le msg TCP fin pour ne pas empecher les nouvelles connections vers le serveur... je vais regarder un peu plus en detail iptables pour connaitre la syntaxe d'une telle regle...
    - [^] # Re: malpropre !
      
      Posté par Obsidian le 14 janvier 2007 à 11:57. Évalué à 2.
      
      --tcp-flags [!] mask comp
      
      Match when the TCP flags are as specified. The first argument is the flags which we should examine, written as a comma-separated list, and the second argument is a comma-separated list of flags which must be set. Flags are: SYN ACK FIN RST URG PSH ALL NONE. Hence the command iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST SYN will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset.
      
      [!] --syn
      
      Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is inverted.
      
      man page powah ! :-)
- [^] # Re: malpropre !
  
  Posté par str000mff le 12 janvier 2007 à 16:46. Évalué à 1.
  
  merci pour tous tes conseils. j'avais effectivement pensé à débrancher la prise, mais comme c'est un test de charge je n'ai pas vraiment envie de brancher-rebrancher-brancher-rebrancher-brancher .... pour ce qui est de descendre l'interface, ce n'est pas une idée idiote - idée similaire : j'avais pensé à regler le firewall , mais comme mon petit tester a besoin de la connexion tout au long du test je ne pourrais pas m'en contenter. A mon avis la meilleur solution est donc de stop proprement les process, en esperant que derriere le noyau ne ferme pas proprement la socket. Je vais la tenter....
- [^] # Re: malpropre !
  
  Posté par str000mff le 19 janvier 2007 à 14:49. Évalué à 1.
  
  Bon j'ai eu des resultats interressant avec le SIGSTOP, cependant il faut penser à bien envoyer un SIGKILL sur les process parceque au bout d'un moment y'en à trops :) Mais enfin de compte, tant que ne les kill pas trops tot (en gros temps attente > timeout tcp), on a bien une mauvaise deconnexion. Du coup je n'ai meme pas essaillé de configurer mon firewall avec les flags TCP :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.