Example of how Python implements a daemon

Process guard: it is usually defined as a background process and does not belong to any terminal session ). Many system services are implemented by daemon, such as network services and printing. The following is an example of how Python implements the daemon. Process guard: it is usually defined as a background process and does not belong to any terminal session ). Many system services are implemented by daemon, such as network services and printing. The following is an example of how Python implements the daemon.

Scenario settings:

You have compiled a python service program and started it under the command line. your command line session is controlled by the terminal. The python service becomes a sub-process of the terminal program. Therefore, if you close the terminal, the command line program will also be closed.

To enable your python service to stay in the system without being affected by the terminal, you need to turn it into a daemon process.

Daemon is a Daemon program that is executed in the background of the system. it is independent of the control terminal and executes some cyclic tasks or trigger events. it is usually named "d" at the end of the letter, such as httpd, syslogd, systemd, and dockerd.

Code implementation

Python can easily implement the daemon process. The following code and corresponding comments are provided:

# Coding = utf8import osimport sysimport atexitdef daemonize (pid_file = None): "create daemon: param pid_file: file for saving the process id: return: "# from the parent process fork a sub-process pid = OS. fork () # The pid of the sub-process must be 0, and the parent process must be greater than 0 if pid: # exit the parent process, sys. exit () method than OS. the _ exit () method will execute more refresh buffering jobs. sys. exit (0) # The Child process inherits the working directory of the parent process by default. it is best to change it to the root directory. Otherwise, the unmount OS of the file system is affected. chdir ('/') # The Child process inherits the umask (file permission mask) of the parent process by default, and is reset to 0 (full control) to avoid affecting the OS of the program's read and write files. umask (0) # Let the sub-process become the new session leader and process leader OS. setsid () # Note: Here is the 2nd fork, that is, the sub-process of the sub-process. We call it the Sun Tzu process _ pid = OS. fork () if _ pid: # exit the sub-process sys. exit (0) # at this time, the Sun Tzu process is already a daemon. Next, we redirect the standard input, output, and error descriptor (which is redirection instead of shutting down, this will avoid program errors during print) # refresh the buffer first, and carefully make the ship sys. stdout. flush () sys. stderr. flush () # The dup2 function closes and copies file descriptors atomically, redirects to/dev/nul, that is, discards all input and output with open ('/dev/Null') as read_null, open ('/dev/Null', 'w') as write_null: OS. dup2 (read_null.fileno (), sys. stdin. fileno () OS. dup2 (write_null.fileno (), sys. stdout. fileno () OS. dup2 (write_null.fileno (), sys. stderr. fileno () # write the pid file if pid_file: with open (pid_file, 'W + ') as f: f. write (str (OS. getpid () # register the exit function. when a process exits abnormally, the pid file atexit is removed. register (OS. remove, pid_file)

The following describes how to write the daemon process:

1. Fork is used to exit the parent process.

2. Sub-process change working directory (chdir), file permission mask (umask), Process Group and session group (setsid)

3. Child process fork child process, exit child process

4. Sun Tzu process refresh buffer, redirection standard input/output/error (usually to/dev/null, meaning to discard)

5. (Optional) pid for file writing
   

Several key points

Why do I have to fork twice?

For the first fork, it was used to get out of the control of the terminal. The reason why the parent process exits is that it is sent a signal when the terminal strikes the keyboard or closes the process. The child process that comes out of fork becomes an orphan process after the parent process commits suicide, it is taken over by the init process of the operating system and thus is out of the control of the terminal.

Therefore, the second fork is not necessary (many open-source projects do not have the code fork twice ). It is only for careful consideration that the process is prevented from opening a control terminal again. Because the sub-process is now the session leader (the first process in the dialog period), and has the ability to open the control terminal and fork again, the Sun Tzu process cannot open the control terminal.

File descriptor

Linux is "everything is a file". the file descriptor is the index created by the kernel for opened files. it is usually a non-negative integer. Processes perform IO operations through file descriptors.

By default, 0 indicates the standard input, 1 indicates the standard output, and 2 indicates the standard error.

Umask permission mask

We know that in Linux, any file has three permissions: read, write, and execute. The number 4 indicates the read permission. the write permission is 2 and the execution permission is 1. You can run the ls-l command to view the file permissions. r/w/x indicates that you have the read, write, and execute permissions.

All files have three identity permissions: User, User Group, and Others. Generally, three numbers are used to indicate the file permission, for example, 754:

7. it is the User permission, that is, the file owner permission.

5. it is the Group permission and the permissions of the members of the user Group in which the owner belongs.

4. Others permission, that is, the permissions of users in other groups.

Umask is used to control default permissions and prevent full permissions on new files or folders.

Generally, the default value is 022 (run the umask command to view details), indicating that the default file creation permission is 644, and the folder is 755. You can see that their rule is that the sum of file permissions and umask results in 666 (laugh), and the sum of folder permissions and umask results in 777.

Process Group

Each Process belongs to a Process Group (PG, Process Group). a Process Group can contain multiple processes.
A Process Group has a Leader. The PID (Process ID) of the Process Leader serves as the ID (PGID, Process Groupd ID) of the whole Process Group ).

Session Group

When logging on to the terminal, a session is created. multiple process groups can be contained in one session. The process for creating a session is the session leader.
The process already belongs to the session leader. you cannot call the setsid () method to create a session. Therefore, in the code above, the child process can call setsid (), but the parent process cannot, because it is the session leader.

In addition, sh (Bourne Shell) does not support the session mechanism, because the session mechanism requires shell to support Job Control ).

Daemon and background processes

The & symbol can be used to place commands in the background for execution. It is different from the daemon process:

1. The daemon process is an orphan process adopted by the init process. the parent process of the background process is a terminal and can still be printed on the terminal.

2. The daemon process remains strong when the terminal is closed, and the background process stops as the user exits, unless nohup is added.

3. The daemon changes sessions, process groups, working directories, and file descriptors. background processes directly inherit
   

In other words, the Daemon process is a promising young man who struggles silently, while the background process is a rich generation that silently inherits dad's assets.

For more information about how to implement the daemon in Python, refer to PHP!