Botnets and how to handle botnets

#include <stdio.h>#include <sys/wait.h>#include <sys/types.h>#include <unistd.h>int main(void)   {      pid_t pid;         if ((pid = fork()) < 0)       {           fprintf(stderr,"Fork error!/n");           exit(-1);       }       else if (pid == 0) /* first child */      {            if ((pid = fork()) < 0)           {                fprintf(stderr,"Fork error!/n");               exit(-1);           }           else if (pid > 0)               exit(0); /* parent from second fork == first child */          /*           * We‘re the second child; our parent becomes init as soon           * as our real parent calls exit() in the statement above.           * Here‘s where we‘d continue executing, knowing that when           * we‘re done, init will reap our status.           */          sleep(2);           printf("Second child, parent pid = %d/n", getppid());           exit(0);       }              if (waitpid(pid, NULL, 0) != pid) /* wait for first child */      {           fprintf(stderr,"Waitpid error!/n");           exit(-1);       }         /*       * We‘re the parent (the original process); we continue executing,       * knowing that we‘re not the parent of the second child.       */      exit(0);   }   

Fork two times in the prevention of death, it is because the son process first exited, the son process was taken over by init, in fact, with the initial parent process out of the relationship, will not be frozen. See the following description of apue p151:

Recall the discussion about dead processes in Section 8. 5. If a process requires a sub-process of f o r k, but does not require it to wait for the sub-process to terminate, and does not want the sub-process to be frozen until the parent process ends, the trick to achieve this is to call f o r k twice. The Program 8-5 implements this. Call s l e p in the second child process to ensure that the first child process is terminated when the parent process I D is printed. After f o r k, the Parent and Child processes can continue to execute -- we cannot predict which one will be executed first. If the second child process is not sleep, after f o r k, it may be executed first than its parent process, so the parent process I d it prints will be the parent process that created it, instead of the I n I t process (process ID 1 ).
The other role of the two forks is to do daemon.

void InitAsDaemon()   {    if (Fork() > 0)     exit(0);      setsid();      Signal(SIGINT, SIG_IGN);    Signal(SIGHUP, SIG_IGN);    Signal(SIGQUIT, SIG_IGN);    Signal(SIGPIPE, SIG_IGN);    Signal(SIGTTOU, SIG_IGN);    Signal(SIGTTIN, SIG_IGN);    Signal(SIGCHLD, SIG_IGN);      if (Fork() > 0)     exit(0);      chdir("/");    umask(0);   }

About zombie processes:

In the fork ()/execve () process, assume that the parent process still exists at the end of the Child process, and the parent process fork () has not installed the sigchld signal processing function to call waitpid () when the sub-process ends and the signal is not explicitly ignored, the sub-process becomes a zombie and cannot end normally. In this case, even the root identity kill-9 cannot kill the zombie process. The remedy is to kill the parent process of the zombie process (the parent process of the zombie process must exist). The zombie process becomes an "orphan process" and passes the process init to process 1, init is always responsible for cleaning up zombie processes.

A zombie process means that the parent process has exited, and the dead process becomes a zombie process without being accepted by the process. how a zombie process generates a zombie process: when a process calls the exit command to end its own life, it is not actually destroyed, instead, it leaves a data structure called Zombie (which calls exit by the system. It is used to exit the process, but it is only limited to converting a normal process into a zombie process, it cannot be completely destroyed ). In the status of a Linux Process, a zombie process is a very special one. It has abandoned almost all the memory space, no executable code, and cannot be scheduled, only one location is retained in the process list, and information such as the return status of the process is recorded for collection by other processes. In addition, zombie processes no longer occupy any memory space. It requires its parent process to collect dead parts for it. If its parent process does not install the sigchld signal processing function, call wait or waitpid () to wait until the child process ends, if the signal is not explicitly ignored, it will remain in zombie state. If the parent process ends, the INIT process will automatically take over the child process and send a zombie to it, it can still be cleared. However, if the parent process is a loop and does not end, the child process will remain zombie, which is why many zombie processes sometimes exist in the system. How to view zombie processes: using the command ps, we can see that a process marked as Z is a zombie process. How to clear zombie processes: 1. Rewrite the parent process and collect dead parts for it after the child process dies. The specific method is to take over the sigchld signal. After a child process dies, it sends a sigchld signal to the parent process. After receiving the signal, the parent process executes the waitpid () function to collect the child process. This is based on the principle that even if the parent process does not call wait, the kernel will send sigchld messages to it, even though the default processing is ignored. If you want to respond to this message, you can set a processing function. 2. Kill the parent process. After the death of the parent process, the zombie process becomes an "orphan process". After it passes through to the INIT process on process 1, init will always be responsible for cleaning up the zombie process. All the zombie processes it generates will also disappear. ========================================================== === In Linux, you can use PS auwx to find the zombie process a all w/tty, including other users all windows and terminals, including processes of other users U user-oriented for users (user friendly)-W, w ide output wide format output x processes W/O controlling TTYs will mark PS axf to view the process tree behind the zombie process, and the PS axm will list the threads in a tree-shaped realistic process list, in Linux, processes and threads are unified. They are two lightweight processes. PS axu displays the detailed process status ============================================== ========== killall kill-15 kill-9 generally cannot kill the defunct process with kill-15, after kill-9, more zombie processes will be added, and kill-kill PID Fuser-k pid can be considered as killing its parent process, kill-9 its parent process ====================================== =========== a terminated, however, a parent process that has not processed it well (obtains information about the child process and releases the resources it still occupies) is called a dead process (zombie process ). Avoid zombie: 1) In svr4, IF signal or sigset is called to set the sigchld configuration to ignore, no dead child process will be generated. In addition, you can set the sa_nocldwait flag to prevent sub-processes from freezing. You can also use this function in Linux, and call this function signal (sigchld, sig_ign) at the beginning of a program; 2) Call fork twice. The Program 8-5 implements this. 3) Use waitpid to wait for the sub-process to return. ========================================================== === zombie processes are zombie processes. First, use functions such as wait and waitpid to obtain the termination status of the process to release resources. The other is fork twice ============================================== ========= defunct process only has a record in the process table, other resources are not occupied. Unless the number of processes in your system exceeds the limit, zombie processes will not have more disadvantages. The only possible method is that the reboot system can eliminate the zombie process. ========================================================== === Any program is in zombie state, it occupies a bit of memory resources (that is, there is a record in the Process Table). It is just a representation and you don't have to be afraid. If there is a problem with the program, the simple and effective way to solve a large number of botnets is to restart. Kill is the way in which some processes in UNIX run fork and zombie/defunct without any effect. When a process dies, it does not completely disappear. The process is terminated, and it does not run any more, but there are some residual things waiting for the parent process to be withdrawn. These residual things include the returned values of sub-processes and other things. When the parent process fork () is a sub-process, it must use wait () or waitpid () to wait for the sub-process to exit. It is this wait () action that makes the child process residue disappear. Naturally, there is an exception in addition to the above rules: the parent process can ignore sigcld soft interruptions without wait (). You can do this (on a system that supports it, such as Linux ):

main()      　　{      　　signal(SIGCLD, SIG_IGN); /* now I don‘t have to wait()! */      　　.      　　.      　　fork();      　　fork();      　　fork(); /* Rabbits, rabbits, rabbits! */      　}  

Now, when a child process dies, the parent process does not have wait (). Usually PS shows it as "". It will always remain this way until the parent process wait (), or as follows.
Here is another rule you must know: when the parent process dies before its wait () child process (assuming it does not ignore sigcld), the child process will put Init (PID 1) process as its parent process. This is not a problem if the sub-process works well and can be controlled. However, if the sub-process is already defunct, we will have a little trouble. Look, the original parent process can no longer wait (), because it has vanished. In this way, how does init know the zombie processes such as wait.
Answer: unpredictable. In some systems, init periodically destroys all of its defunct processes. In other systems, it simply rejects the parent processes of any defunct process, but destroys them immediately. If you use one of the above systems, you can write a simple loop and fill the process table with the defunct process that belongs to init. This probably won't make your system administrator very happy, right?
Your task: Make sure that your parent process does not ignore sigcld or wait () It fork () all processes. However, you may not always do this (for example, you want to start a daemon or something else), but you must be careful with programming if you are a newbie to fork. In addition, do not be psychologically bound.
Summary:
The child process becomes defunct until the parent process wait (), unless the parent process ignores sigcld.
Furthermore, the child process (active or defunct) of the parent process that does not have wait () disappears (assuming that the parent process does not ignore sigcld) becomes the child process of init, init processes them in a heavy way.

Botnets and how to handle botnets