Knowledge of Linux creation Daemon _linux shell

Create child process, parent process exits

This is the first step in the process of writing a daemon. Since the daemon is detached from the control terminal, the first step is to create the illusion that a program has been completed in the shell terminal. All subsequent work is done in the subprocess, and the user can execute other commands in the shell terminal, thus achieving a formal separation from the control terminal.
In Linux, the parent process exits before the child process, which causes the subprocess to become an orphan process, and is automatically adopted by the 1th process (init) whenever the system discovers an orphan process, so that the original subprocess becomes a subprocess of the init process.

create a new session in a child process

This step is the most important step in creating a daemon, although its implementation is very simple, but it is very significant. The system function Setsid is used here, and before you introduce SETSID, you should first understand two concepts: process groups and session sessions
Process group: is a collection of one or more processes. The process group has a process group ID to uniquely identify. In addition to the process number (PID), the process group ID is also a prerequisite for a process. Each process group has a leader process with the process number of the leader process equal to the process group ID. And the process group ID will not be affected by the exit of the leader process.

Session Period: Session period is a collection of one or more process groups. Typically, a session begins to log in with the user, terminating the user's exit, during which all processes that the user runs are part of this session period.

Then you can specifically describe the SETSID:

(1) Functions of setsid function:

The SETSID function is used to create a new session and act as the leader of the conversation group. The call Setsid has the following 3 functions:
Let the process get rid of the control of the original session
Let the process get rid of the control of the original process group
Let the process get rid of the control of the original control terminal

So why do you call the SETSID function when you create the daemon? The first step in creating the daemon calls the fork function to create the child process and then exits the parent process. Because when the fork function is invoked, the child process copies the session period of the parent process completely, process group, control terminal, etc., although the parent process exits, but the session, process group, control terminal, and so did not change, so it is not really a sense of independence, and the SETSID function can make the process completely independent, Thus getting rid of the control of other processes.

change the current directory to the root directory

This step is also a necessary step. The child process created using fork inherits the current working directory of the parent process. Because the current directory's file system (such as "/MNT/USB") cannot be unloaded while the process is running, this can cause a lot of trouble for future use (for example, the system has to enter Single-user mode for some reason). Therefore, it is common practice to have "/" as the current working directory of the Daemon, so that the above problems can be avoided, and of course, if you have special needs, you can change your current working directory to another path, such as/tmp. Change the common functional chdir of the working directory.

To reset a file permission mask

A file permission mask refers to the corresponding bit in the masked file permissions. For example, if a file permission mask is 050, it masks the readable and executable permissions of the filegroup owner. Because the newly created child process using the Fork function inherits the file permission mask of the parent process, this creates a lot of trouble using the file for the child process. Therefore, setting the file permission mask to 0 can greatly enhance the flexibility of the daemon. The function that sets the file permission mask is umask. In this case, the usual method of using Umask (0).

Close File Descriptor

As with file permission codes, a newly created subprocess with the fork function inherits some files that have already been opened from the parent process. These open files may never be read or written by the daemon, but they consume system resources as well, and may cause the file system in which they reside to not be unloaded.