Daemon programming rules

Daemon is a process with a long lifetime. They are often started during system boot loading.
It is terminated when it is disabled. Because they do not have control terminals, they are running in the background. UNIX systems have a lot of genie
Processes, which execute daily things. We often use the genie process when writing a program. The following describes the programming rules of the genie process and provides an example. 1: Call fork to generate a sub-process, and the parent process exits. All subsequent work is completed in the sub-process. In this way, we can: If we execute the program from the command line, this may lead to the illusion that the program has been executed, shell will go back and wait for the next command; the new process generated through fork will not be the leader of a process group, which provides a prerequisite for the implementation of step 1. In this case, a very interesting phenomenon occurs: because the parent process has exited before the child process, it will cause the child process to have no parent process and become an orphan process (orphan ). Every time the system finds an orphan process, it will be automatically adopted by process 1, so that the original child process will become the child process of process 1. 2: Call the setsid system call. This is the most important step in the process. For details about setsid, see Appendix 2. It is used to create a new session and act as the session leader ). If the calling process is the leader of a process group, the call will fail, but this is guaranteed in step 1. Calling setsid has three functions:
Let the process get rid of the control of the original session;
Remove the process from the control of the original process group;
Let the process get rid of the control of the original control terminal; in short, it is to make the calling process completely independent from the control of all other processes. 3: Switch the current working directory to the root directory. If we execute this process on a temporary file system, such as/mnt/floppy/, the current working directory of the process will be/mnt/floppy /. The file system cannot be detached (umount) during the entire process, and whether or not we are using this file system, this will cause us a lot of inconvenience. The solution is to use the chdir system call to change the current working directory to the root directory. No one wants to unload the root directory. For more information about how to use chdir, see Appendix 1.
Of course, in this step, if there are special needs, we can also change the current working directory to another path, such as/tmp. 4: Set the File Permission mask to 0. This requires that the system call umask be called. See Appendix 3. Each process inherits a File Permission mask from the parent process. When a new file is created, this mask is used to set the default access permissions for the file and block some permissions, for example, the write permission of a general user. When another process uses exec to call our daemon program, because we do not know what the File Permission mask of the process is, it will cause some trouble when we create a new file. Therefore, we should re-set the File Permission mask. We can set it to any value we want, but generally we set it to 0, it does not block any user operations.
5: if your application does not involve creating new files or setting file access permissions, you can also kick off the File Permission mask and skip this step. Close all unnecessary files. Like the File Permission mask, our new process will inherit some opened files from the parent process. These opened files may never be read or written by our daemon process, but they consume the same system resources and may cause the file system to be unable to be detached. It should be noted that the file descriptor is 0, 1, and 2 (the concept of the file descriptor will be introduced in the next chapter ), that is to say, the input, output, and error files also need to be closed. Many readers may wonder this. Do we not need input or output? But the fact is that after Step 1 above, our daemon process has lost contact with the control terminal, and the characters we input from the terminal cannot reach the daemon process, the daemon process output characters using conventional methods (such as printf) cannot be displayed on our terminal. Therefore, these three files have lost value and should be closed. We can use the PS-ajx command to observe the daemon process status and some parameters. The first is an example in the Unix advanced programming book, and the second is executable. * A daemon program */<br/> # include <unistd. h> <br/> # include <sys/types. h> <br/> # include <sys/STAT. h> <br/> # define maxfile 65535 <br/> main () <br/> {<br/> pid_t PID; <br/> int I, j = 0; <br/> pid = fork (); <br/> If (PID <0) <br/> {<br/> printf ("error in fork/N "); <br/> exit (1); <br/>} else if (pid> 0) <br/>/* parent process exited */<br/> exit (0); <br/>/* Call setsid */<br/> setsid (); <br/>/* switch the current directory */<br/> chdir ("/"); <br/>/* set the File Permission mask */<br/> umask (0 ); <br/>/* close all unnecessary files that may be opened */<br/> for (I = 0; I <maxfile; I ++) <br/> close (I); <br/>/* <br/> * until now, the process has become a complete daemon process, <br/> * you can add anything you want daemon to do, such as: <br/> */<br/> for (j = 0; j <5; j ++) <br/> sleep (10); <br/>}< br/> # Include <sys/types. h> <br/> # include <sys/STAT. h> <br/> # include <fcntl. h> <br/> # include "outhdr. H "<br/> int <br/> daemon_init (void) <br/>{< br/> pid_t PID; <br/> If (pid = fork ()) <0) <br/> return (-1); <br/> else if (PID! = 0) <br/> exit (0);/* parent goes bye-bye */<br/>/* child continues */<br/> setsid (); /* become session leader */<br/> chdir ("/");/* change working directory */<br/> umask (0 ); <br/> return (0); <br/>}