Linux process Management (i) creation and destruction of processes

On the creation of a process, Unix takes an interesting and uncommon approach: it separates the creation of the process and the loading of a new binary image. UNIX provides two system calls, fork and exec.

To create a process:

By default, the kernel restricts the maximum value of the process ID to 32768,2^15. The system administrator can set the value of the/proc/sys/kernel/pid_max to break the default limit, but at the expense of some compatibility.

The process that creates the new process is called the parent process, and the new process is called the child process. Each process is created by another process (except for the init process), so each child process has a parent process. This relationship is saved in the parent process ID number (PPID) of each process. Each process is owned by one user and group. This dependency is used to implement access control. Each process is part of a process group, which simply indicates the relationship between itself and other processes, but not with the concepts of the users and groups above. A child process usually belongs to the same process group as the parent process. Process groups make it easy to send and retrieve information between pipelines-related processes, which also applies to child processes in the pipeline. From a user's point of view, a process group is more like a task.

In Unix, the operation to load memory and execute a program image is detached from the operation of creating a new process. UNIX has a system call (actually one of a series of system calls) that can load a binary file's program image into memory, replace the original process's address space, and start running it. This process is called running a new program, and the corresponding system call is called the EXEC system call. At the same time, another different system call is to create a new process that basically replicates the parent process. Typically, a new process executes a new program immediately. This behavior of creating a new process is called derivation (fork), and the system call to complete this function is fork ().

int execl (const char path, const char arg, ...);
EXECL () The successful invocation not only changed the image of the address space and process, but also changed some of the properties of the process:
1, any pending signals will be lost.
2, any signal captured will revert to the default processing because the signal processing function is no longer present in the address space.
3, any memory lock (see chapter eighth) will be lost.
4, the properties of most threads are restored to the default values.
5, most of the statistical information about the process will be reset.
6, any data associated with the process memory will be lost, including the mapped file.
7, data that is isolated in user space, including some features of the C language library (such as atexit ()), are lost.
However, there are also many process properties that do not change, such as PID, PID of the parent process, priority, the user and group to which it belongs.
Five other system calls: Execlp,execle,execv,execvp,execve. The letters L and V indicate that the parameters are provided in a list or array (vector) manner. The letter p means looking for an executable file in the user's path environment variable. As long as it appears in the user's path, the EXEC function with P can simply provide the file name. The last e represents the new environment variable that will be provided to the new process.

pid_t fork (void);
A successful fork () call returns 0. Fork () returns the PID of the child process in the parent process. In addition to some of the necessary aspects, the parent and child processes are very similar in each respect:
1, it is clear that the PID of the child process is newly assigned, which is different from the parent process.
2, the ppid of the child process is set to the PID of the parent process.
3, the resource statistics (Resource statistics) in the child process are zeroed.
4, any pending signal will be cleared, nor will the quilt process inherit (see Chapter Nineth).
5, any file lock will not be inherited by the quilt process.

Write-time replication is a lazy optimization method to avoid the overhead of replication. Its premise is simple: if there are multiple processes to read copies of their own portion of the resource, then replication is unnecessary. Each process simply saves a pointer to the resource. As long as there is no process to modify their "copy", there is the illusion that each process seems to monopolize that resource. Thus avoiding the burden of duplication. If a process is to modify its own copy of the resource, it will replicate that resource and make the copy available to the process. However, replication is transparent to the process. This process can modify the replicated resources, while other processes still share the unmodified resource.
The implementation of copy-on-write in the kernel is straightforward. The data structures associated with the kernel page can be marked as read-only and copy-on-write. If there is a process attempting to modify a page, a fault is generated. The way the kernel handles page break processing is to make a transparent copy of the pages. The Cow property of the page is cleared, indicating that it is no longer shared.

Unix designers have been concerned about the waste of address space caused by exec immediately after the fork, before implementing a write-time copy. Vfork () suspends the parent process until the child process terminates or runs an image of a new executable file. In this way, vfork () avoids page-by-copy of the address space. In fact, vfork () only accomplishes one thing: Copy the internal kernel data structure. Therefore, the child process cannot modify any memory in the address space.

Terminating a process
When the process exits successfully, simply write: Exit (exit_success);
Before terminating a process, the C language function performs the following shutdown process:
1, the function registered by atexit () or On_exit () is called in reverse order registered in the system.
2, empty all open standard I/O streams.
3, delete all temporary files created by Tmpfile ().
These steps complete what needs to be done in the user space so that exit () can call _exit () to allow the kernel to handle the remaining work of the terminating process.
The kernel cleans up any resources that the process creates that are no longer in use. This includes: Requested memory, open files, and SystemV semaphores. After the cleanup is complete, the kernel destroys the process and informs the parent process of its child process termination.
In the C language, when the main () function returns, the compiler simply inserts a _exit () in the final code. The shell will determine whether the command executes successfully based on this return value, explicitly giving a state value when the main () function returns, or calling exit (), which is a good programming habit.

A successful call to Atexit () registers the specified function (no parameter, no return value) into the function that is called when the process ends normally (for example, when a process calls exit () or terminates itself in the way returned from main (). If the process calls exec, the list of registered functions is cleared (because these functions do not exist in the new process's address space). If the process ends with a signal, these registered functions are not called.
The order of function calls is the reverse of the order of registration. That is, these functions are stored in the stack and are called in a LIFO manner (LIFO). The registered function cannot call exit (), otherwise it will cause an infinite recursive call.

SunOS 4 defines one of its own and atexit () equivalent function on_exit (), the function works in the same way as the atexit ()-like, except that the registered function prototypes are different.

When a process child process terminates, the kernel sends a sigchild signal to its parent process. This semaphore is ignored by default, and the parent process does not have any action. The process can also be used by the signal () or sigaction () system to selectively process this signal. Typically, the parent process wants to be more aware of the child process's termination, or explicitly wait for the child process to terminate.

Users and Groups
users and groups: Linux is authenticated by users and groups, and each user is associated with a unique positive integer, called the User ID (UID). Each process is associated with a series of user IDs:
Real UID: Each process is associated with a user ID to identify the user who is running the process. Used to identify the true owner of a process and affect the permissions that the process sends a signal. A process that does not have superuser privileges can send a signal to the target process only if its ruid matches the ruid of the target process, such as between parent and child processes, where the child process inherits authentication information from the parent process, allowing the parent-child process to send signals to each other.
Valid UID (effective UID): works when creating and accessing files. Specifically, when a file is created, the system kernel sets the owner/group properties of the file based on the Euid and egid of the process that created the file, and when the file is accessed, the kernel also determines whether it can access the file based on the Euid and egid of the access process.
Preserve uid (saved UID): used when a process running with elevated privileges temporarily needs to do something that does not require privilege, in which case the process temporarily changes its valid user ID from the UID corresponding to a privileged user (often root) to the corresponding UID of a non-privileged user. The original privileged user UID is then replicated as SUID, and after the process has completed an operation that does not require a privilege, the process resets the euid with the value of suid to regain privileges. It should be explained here that the Euid value of the unprivileged process can only be set to the same value as Ruid, Suid, and Euid (that is, unchanged).
File System UID (filesystem UID): Used in Linux, and only for the access control of the file system, the same as Euid without explicit settings (if Fsuid is the UID of root, then suid, Ruid and Euid must have at least one root uid), and euid changes will also affect Fsuid. The Fsuid is set up to allow programs (such as Server for NFS) to qualify their file system permissions without having to get a signal to a given UID account with a given UID.

Sessions and process groups
Each process belongs to a process group. A process group consists of one or more processes that are associated with each other, and is intended for job control. The main feature of a process group is that signals can be sent to all processes in a process group: this signal can cause all processes in the same process group to terminate, stop, or continue running. Each process group is uniquely identified by the Process group ID (PGID) and has a leader process. The Process group ID is the PID of the leader process. A process group exists as long as there is another process in a process group. Even if the leader process is terminated, the process group still exists.
When a new user logs on to the computer, the login process creates a new session for the user. Only the user's login shell-a process in this session. Login Shell as session leader. The PID of the session's first process is used as the session ID. A session is a collection of one or more process groups. The session contains all the activities of the logged-on user and is assigned to the User A control terminal (Controling terminal). The control terminal is a TTY device for handling user I/O. Thus, the function of the session is similar to that of the shell. No one deliberately distinguishes them.
A process group in a session is divided into a foreground process group and 0 or more background process groups. When the user exits the terminal, the sigquit signal is sent to all processes in the foreground process group. When a network outage occurs, a sighup signal is sent to all processes in the foreground process group. When the user has typed the terminating key (typically CTRL + C), it sends a SIGINT signal to all processes in the foreground process group.

Related system call: Setsid,getsid,setpgid,getpgid.

Special processes:
Init process
Idle Process
Idle process, when no other process is running, the kernel runs the process-its PID is 0.
Init process, after booting, the kernel runs the first process called the INIT process, its PID is 1. Unless the user explicitly specifies which program the kernel is running (through the kernel-initiated init parameter), the kernel looks for an init program in turn, and the first discovery is run as init. If all fails, the kernel will issue panic and suspend the system. After the kernel has surrendered control, Init will then complete the subsequent boot process. Typically, init initializes the system, launches various services, and initiates the login process.

Orphan process Orphan processes

Zombie Process Zombie Processes
Child process waiting to terminate
It is possible to notify the parent process with a signal, but many parent processes want to know more about the termination of a child process-such as the return value of a child process. If the child process completely disappears during the finalization process, it does not leave anything for the parent process to understand the child process. The UNIX designers made the decision that if a child process ends before the parent process, the kernel should set the process to a special state. A process in this state is called a zombie (zombie) process. The process retains only the smallest profile. A few kernel data structures that hold useful information (process number, exit status, run time, and so on). The zombie process waits for the parent process to query its own information (this is called Waiting on a zombie process). As long as the parent process obtains the child process information, the child process disappears, otherwise it remains in a zombie state.
To avoid zombie processes, such as a process can show waiting for a child process to end, process, or ignore SIGCHLD signals.

pid_t Wait (int status);
pid_t waitpid (pid_t pid, int status, int options);
int Waitid (idtype_t idtype, id_t ID, siginfo_t *infop, int options);
Wait () returns the PID of the terminated child process, or 1 indicates an error. If no child processes are terminated, the caller is blocked until a child process terminates.

int system (const char *command);
Both ANSI and POSIX define a function to create a new process and wait for it to end-it can be imagined as a synchronous creation process.

As soon as the process is finished, the kernel iterates through all its child processes and resets their parent process to the INIT process (the PID 1 process). This ensures that there are no processes in the system that do not have a parent process. The init process periodically waits for all child processes to ensure that there are no zombie processes that persist for a long time.

Daemon Process Daemon
The daemon runs in the background and is not associated with any control terminal. Daemons typically run at system startup, run as root users or other special users (such as Apache and Postfix), and handle some system-level tasks. The customary daemon name usually ends with D (like Crond and sshd), but this is not necessary or even generic. There are two basic requirements for a daemon: it must be a child of the INIT process and not be associated with any control terminal.

In general, a process can become a daemon through the following steps:
1, call fork (), create a new process, it will be the future daemon.
2, call exit () in the parent process of the daemon. This ensures that the daemon's grandparent process confirms that the parent process has ended. It also ensures that the parent process is no longer running, and the daemon is not the leader process. The last point is the prerequisite for successful completion of the following steps.
3, call Setsid () so that the daemon has a new process group and a new session, both of which take it as the first process. This also guarantees that it will not be associated with the control terminal (because the process has just created a new session and does not have a control terminal associated with it).
4, use ChDir () to change the current working directory to the root directory. Because the previous call to fork () creates a new process, the current working directory it inherits from may be anywhere in the file system. The daemon usually runs at system startup and does not want some random directories to remain open, preventing the administrator from uninstalling the file system where the daemon's working directory resides.
5, close all file descriptors. You do not need to inherit any open file descriptors, so that they remain open for file descriptors that cannot be confirmed.
6, open the 0, 1, and 2nd file descriptors (standard input, standard output, and standard error) and redirect them to/dev/null.

Linux process Management (i) creation and destruction of processes