Deep understanding of daemon processes from the concept of process groups, sessions, and endpoints

Deep understanding of daemon processes from the concept of process groups, sessions, and endpoints

First, write in front

"Daemon" is a long-running background service process of Linux, and some people call it "daemon process". Our common httpd, named, sshd and other services are run in the daemon Daemon way, usually the service name ends with the letter D, that is, the first letter of Daemon. It probably has the following characteristics compared to the normal process:

• No control terminals (no need to interact with users)
• Running in the background
• Long life cycle, typically with system startup and shutdown

Ii. necessity of the Guardian process

Why set as daemon, normal process can not?

When we enter a similar program at the command ./helloworld -line prompt, the terminal is occupied when the program runs, and no other action can be performed at this time. Even ./helloworld & when running in the background, there is a problem with the network connecting to the terminal, which can also cause the running program to break. These factors are unfriendly to long-running services, and the "daemon" is a good solution to this problem.

Iii. understanding of process groups, sessions and terminals

The "daemon" is not complicated to understand, and the code is written with a basic set of routines. If you want to understand the fundamentals of daemon, you must first understand the concepts of Linux processes, process groups, sessions, terminals, and so on.

1. Process

• Process is the smallest unit of Linux for resource allocation
• Foreground processes, such as this:$ ./hello
• A background process, such as this: releasing the use of the $ ./hello & control terminal

2. Process Group

Each process belongs to a process group, and the process group can contain one or more processes. There is a process leader in the process group, the process ID of the leader is the process group ID (pgid)

ps|cat  PID  PGID  PPID  COMMAND10179  10179 10177 bash10263  10263 10179 ps10264  10263 10179 cat

Below is a simple example to understand the process group

• BASH: Both process and process group IDs are 10179, and the parent process is actually sshd (10177)
• PS: Both the process and the process group ID are 10263, and the parent process is bash (10179) because it is a command executed on the Shell
• Cat: The process group ID is the same as the PS process group ID, and the parent process is also bash (10179)

Easy to understand Bash is the shell process, the shell parent process is sshd;ps with the cat through the pipe symbol, belong to a process group, its parent process is Bash; a process group is also called a "job."

3. Sessions (session)

More than one process group constitutes a "session", the process that establishes the session is the lead process for the session, and the process ID is the SID of the session. Each process group in a session is called a "job". A session can have a process group called a "foreground job" for a session, and other process groups are "background jobs"

A session can have a control terminal, which is passed to the foreground process group when the control terminal has input and output, for example Ctrl + Z . The meaning of a session is that multiple jobs can be controlled through one terminal, one foreground operation and the other running in the background.

4. Operation related to front and rear work

Let the job run into the background:

ping>&[1] 10269    # 终端显示# [1]：作业ID  10269：进程组ID

Send signal to Background job SIGTERM

kill -SIGTERM -10269  # 发信号给进程组kill -SIGTERM %1      # 发信号给作业1

To have the background process switch to the foreground:

fg %1# ping 进程重新切到前台

Iv. Preparation of Daemons

Writing daemons may seem complicated, but they are actually followed by a specific process.

1. Create child process, parent process exits

After the process fork, the parent process exits. There are 2 reasons for doing this:

• If the daemon is started by the shell and the parent process exits, the shell will assume that the task is complete and the child process is adopted by Init
• The child process inherits the process group ID of the parent process, guaranteeing that the child process is not the process group leader, because the calling setsid() request must not be the process leader

2. Create a new session for the child process

Call setsid() to create a new session, and become the leader of an additional conversation. This step is primarily related to the session, process group, and terminal detachment that inherits the parent process.

3, prohibit the sub-process to reopen the terminal

At this point, the child process is the session leader, in order to prevent the child process from reopening the terminal, fork again to quit the parent process, that is, this child process. At this point, child process 2 is no longer the session leader and can no longer open the terminal. In fact, this step is not necessary, but the addition of this step will appear more rigorous.

4. Set the current directory as the root directory

If the current working directory of the daemon is a /usr/home directory, the administrator /usr will error when uninstalling the partition. To avoid this problem, you can call the chdir() function to set the working directory to the root directory / .

5. Set File permission mask

The file permission mask refers to the corresponding bit in the file permission that is masked out. Because the fork() new child process using the function inherits the file permission mask of the parent process, this creates a lot of trouble for the child process to use the file. Therefore, setting the file permission mask to 0 can greatly enhance the daemon's flexibility. The usual method of use is umask(0) .

6. Close File descriptor

Child processes inherit files that are already open, they occupy system resources, and may cause the file system that resides to fail to unload. At this point the daemon and the terminal detachment, often said input, output, error descriptor should also be closed.

V. The error handling of the Guardian process

Because the daemon is out of the terminal, error messages cannot be output to the control terminal, even if GDB does not debug properly. A common approach is to use the Syslog service to enter error information into the /var/log/messages .

Syslog is a system log management service in Linux that is maintained by the daemon syslogd. The daemon reads a configuration file at startup /etc/syslog.conf . This file determines where different kinds of messages are sent.

Vi. Daemon Encoding Example

pid_t PID, sid;intI;openlog ("Daemon_syslog", Log_pid, log_daemon);p id = fork ();//1th stepif(PID <0) Exit (-1);Else if(PID >0) Exit (0);//parent process exits for the first timeif(SID = Setsid ()) <0)//2nd step{Syslog (Log_err,"%s\ n","Setsid"); Exit (-1);}//3rd step the second time the parent process exitsif(PID = fork ()) >0) Exit (0);if(SID = ChDir ("/")) <0)//4th step{Syslog (Log_err,"%s\ n","ChDir"); Exit (-1);} Umask0);//5th step//Step 6th: Close inherited file descriptors for(i =0; I < getdtablesize (); i++) {close (i);} while(1) {do_something ();} Closelog (); Exit (0);

To here basically the Guardian process of the contents of all clear, a lot of content, the concept is more obscure, if you want to understand the more thorough, may need to see more than a few times.

Deep understanding of daemon processes from the concept of process groups, sessions, and endpoints