Linux Multi-task programming (vii) Linux daemon and its basic experiment

Daemon Overview

Daemon, also called daemon process (somehow, I suddenly remembered the vampire Diary of Damon, very good-looking American drama), Linux in the background service process. He is a long-running process that is usually independent of the control terminal and periodically performs a task or waits to handle some of the events that occur. The daemon is often started during system boot loading and terminates when the system shuts down. Linux has many systems, services, and most services are implemented through daemons. At the same time, the daemon can accomplish a number of system tasks, such as the job planning process cronf, the print process LQD, and so on (where the end letter D is the meaning of daemon).

In Linux, each system and user interface called the terminal, each from the end of the process will be attached to the terminal, this terminal is called the control terminal of these processes, when the control terminal shutdown, the corresponding process will automatically shut down. The daemon, however, can break through this limitation by running from execution until a signal is received or the entire system shuts down. If you want a process to be unaffected by user, terminal, or other changes, you must turn the process into a daemon. Visible, the daemon is very important.

Writing daemon Steps

Writing a daemon follows a specific process, and here's how to create the daemon.

1, the child process is created, and the parent process exits.

This is the first step in the process of writing a daemon. Since the daemon is detached from the control terminal, therefore, the completion of the first step will result in the shell Terminal A program has completed the illusion that all subsequent work in the subprocess to complete, and the user at the shell terminal can execute other commands, so that the form of the control terminal and the separation.

However, when the parent process creates a subprocess and exits, does the child process not have a parent process? This is an interesting phenomenon that does occur in the daemon: because the parent process exits before the child process, it causes the child process to have no parent process and thus becomes an orphan process. In Linux, whenever a system discovers an orphan process, it is automatically adopted by the 1th process (the init process), so that the original subprocess becomes a subprocess of the init process. The key code is as follows;

2. Create a new session in a child process

This step is the most important step in creating a daemon, although it is very simple, but it is very significant. The system function Setsid () is used here to understand the following two concepts: Process groups and session sessions before Setsid () is specifically described.

Process Group. A process group is a collection of one or more processes. Process groups are uniquely identified by the process group ID. 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 whose process number PID equals the process group ID, and the process group ID is not affected by the exit of the leader process. (The leader is gone, then find a team member to serve as the team leader chant)

Session period. A conversation group is a collection of one or more process groups. Typically, a session begins with a user logon, terminating the user's exit, during which all processes that the user runs are part of this session. The relationship between process groups and session periods is shown in Figure 1:

The following is a specific introduction to SETSID ().

The role of the ①setsid () function. The Setsid () function is used to create a new session group and let the process executing this function act as the leader of the conversation group. Calling Setsid () has the following 3 effects:

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, looking back, why do you call the Setsid () function when you create the daemon? So, in the first step of creating the daemon, the fork () function is invoked to create the subprocess and then the parent process exits. As the fork () function is invoked, the subprocess replicates the session period, process group, and control terminal of the parent process in its entirety, although the parent process exits, but the original session, process group, and control terminal have not changed, so it is not a true sense of independence. The Setsid () function enables the process to be completely independent of the control of all other processes.

②setsid function format