I learned about processes in Python

Overview

--A memo that relearned around process generation using python --There is also a subprocess module, but a memo that I implemented and re-studied myself --Memorandum

Premise

--Environment - python: v.3.7.7

Basics

• os.fork() --Fork allows you to copy the process. --The duplicated one is the "child", and the one who made it is the "parent" --The child process returns 0, and the parent process returns ʻidof the child process. --Forked processes do not wait for the parent process to finish processing --Note that if the parent process terminates first, it will remain as a zombie process even if the child process ʻos._exit () --In other words --Fork will branch the process at that point -** Parents do not wait for the end of their children ** --When branching, the return value of fork () is 0 or! 0 to judge whether you are a child or a parent. --As a standard, write whether to wait for the processing of the child process (waitpid etc.) as the processing on the parent process side, leave it to wait, or kill it. --If left unattended, it may remain as a zombie even after the child process ends.
• os._exit() --End the child process created by fork ()
• os.exec() --Execute an external command --ʻExec's argument changes depending on the combination of the following examples --v: Specify the argument of the program to be executed by tuple or list --Example) ʻexecvp ('python', ['python','test.py']) --l specifies a string --Example) ʻexeclp ('python','python','test.py') --p: Find the program to run in the system path (ʻie. PATH) --ʻE: The dictionary of environment variables specified at runtime can be specified as the last argument. If specified, the environment variables (= environment variables set by default in the PC) of the program that called this function will not be inherited, so if you want to add them, add them to the environment variables obtained by ʻos.environ. Pass things
• os.waitpid(sid, option) --Wait until processing of the process ID specified by ʻoption = 0is completed. --If you don't bite this, the process will continue to remain as a zombie even if the child process ʻos._exec (). That is, when a child process tries to terminate, it remains in a zombie state if the parent process has not waited. --If ʻoption = os.WNOHANG`, the state of the child process is judged. At this time, the calling process is not blocked (= does not wait), so it does not keep waiting for the termination of the child process **.
  • os.setid() --Become a process group leader = have a control terminal --Flow until you have a control terminal

1. Create a new session.
2. Make the calling process the leader of a new session.
3. Detach the process from the control terminal.

• memo: ――What happens if the parent waitpid after the child process _exit first? Isn't the child killed first and become a zombie? --The child process was killed by doing a proper waitpid. On the contrary, even if the child finishes the process first, it will become a zombie unless it is waitpid.

application

--In django, implementation example when you want to run the process as a long-time job even after returning the request - double fork --Experiment --Once fork and runscript-> Parent does not wait`` return → Naturally child process becomes zombie --If you fork twice, the grandchild process becomes a child process under init → The grandchild process ends → *** It disappears without becoming a zombie *** --Kimo has the grandchild process daemonized because setsid () is working.

1. The child process becomes the session leader after fork and has a control terminal separate from the parent process.
2. Child process fork grandchild process
3. The child process immediately ʻexit ()and the parent process waits withwaitpid → prevent the child process from being kill and zombied
4. It is obvious that the grandchild process is not a session leader, so it is promised not to have a control terminal as a daemon
5. When the child process ends, the grandchild process will post-process the process under the init process (root), so it will not become a zombie after the process ends. --About sessions and processes --All processes belong to the group that belongs to the session, and there is a hierarchy. --Session (SID) → Process group (PGID) → Process (PID) --The first process in a process group becomes the process group leader --The first process in a session becomes the session leader --A single TTY is associated with every session, and only the session leader can control the TTY. --In order for the process to be daemonized (run in the background), the session leader must be kill so that the session cannot control the TTY.