Process (ii) process specific attributes under Linux __linux

process data structure (process descriptor)

Direct view of the source code (here is the 0.11 version of the kernel) in the file/include/linux/sched.h,linux Process Control block for a structure task_struct defined by the data structure, the structure is in the sched.h above. There is one line of code in this file:
extern struct task_struct *task[nr_tasks];
The pointer array is defined in/KERNEL/SCHED.C for recording pointers to each PCB, and is defined as
struct task_struct * task[nr_tasks] = {& (Init_task.task),};
Nr_tasks is the number of processes that can run at most concurrently, defined in Sched.h (#define NR_TASKS 64).
The contents of the TASK_STRUCT structure are as follows (in order to write a comment there are changes, such as unsigned long start_code,end_code,end_data,brk,start_stack; will expand into multi-line writes):

struct Task_struct {/* These are Hardcoded-don ' t touch/long state;   /*-1 unrunnable, 0 runnable (Ready), >0 stopped/long counter;  
        Task run time slice long priority;    Long signal; Signal.
        Each bit represents a signal.
        struct Sigaction sigaction[32];   Long blocked;  /* Bitmap of masked signals process signal shielding code *//* various fields */int exit_code;  Exit code, the parent process obtains unsigned long start_code;    Code snippet address unsigned long end_code;    Length of code (bytes) unsigned long end_data;    Code length + length of data (bytes) unsigned long brk; Total length unsigned long start_stack; Stack segment address long pid,father,pgrp,session,leader;  process, parent process, process group, session, session first process number unsigned short uid,euid,suid;  User ID, valid user ID, saved user ID unsigned short gid,egid,sgid;                    Group ID, valid group ID, saved group ID long alarm;  Alarm clock timed long utime,stime,cutime,cstime,start_time;      User state (System state) running time, child process user state (System too) unsigned short used_math; is the coprocessor/* file system info used? */int TTY;   The process uses TTY's child device number, the 1 logo does not use unsigned short umask;   File creation screen word struct m_inode * PWD;  Current working Directory I node structure struct m_inode * root;  The root node i node structure struct m_inode * executable;  The execution file I node structure unsigned long close_on_exec;  Closes the file handle bitmap flag struct file * Filp[nr_open] when executed;    The file table structure used by the process/* LDT for this task 0-zero 1-cs 2-ds&ss/struct desc_struct ldt[3]; The local table descriptor for this task.        0-NULL, 1-code snippet cs,2-data segment and stack segment DS&SS/* TSS for this task */struct tss_struct TSS;

 The task State segment information structure of the process};

Process Partial Attribute Description

1. Process ID and parent process ID
2. Actual user ID, actual group ID, valid user ID, valid group ID, saved settings user ID, saved settings Group ID, additional group, file mode Create screen Word
3. Process group ID, session group ID, control terminal
4.tms_utime, Tms_stime, Tms_cutime, Tms_ustime
5. Signal screen Word, signal set, alarm clock
6. File lock (Record Lock)
7. Environmental
8. Running Status

First, Process ID
Each process has an ID, the thread has it, but the process ID number in the system is limited, and the number of processes that may run concurrently is limited, so the process ID number is also a resource. Zombies are processes that are generated when the process ends Hofu processes are not in time to reclaim aborted child processes, and these zombie processes occupy the process ID.

Ii. actual user ID, actual group ID, valid user ID, valid group ID, saved settings user ID, saved settings Group ID, additional group ID
Here are three questions:

1. The issue of competence has always been complex. Let's briefly introduce the next few concepts:
1 actual user ID and actual group ID
These two IDs identify who we are, what user is logged in, and the values do not change between a login session.
2 Valid User ID and valid group ID
These two IDs determine the access rights of our files, and the following details the role of this ID
3 Saved settings User ID and saved settings group ID
Actually a copy of a valid user ID and a valid group ID
4 access rights to files
File access is divided into three categories, owner, group, other, each class has read, write, executable three.
You can set the actual user (group) and valid User (group) IDs with Setuid () Setgid ()
You can change the permissions of the file with chmod (), Chown change the owner of the file and all groups

2. Each time the process opens, creates, or deletes a file, the kernel tests the file access right, and the test is divided into four steps:
1 if the valid user ID of the process is 0 (root), access is allowed.
2 If the valid user ID of the process is equal to the owner ID of the file (that is, the process owns the file), if the owner's appropriate access rights are set, access is allowed, otherwise access is denied.
3 If one of the additional group IDs of the active group or process of the process equals the group ID of the file, then access is allowed if the owner's appropriate access rights are set, otherwise access is denied.
4 If the appropriate access rights of other users are set, then allow access, or reject
Perform four steps sequentially, if the process owns this file (2), annotate or deny the process access to the file by user access, without viewing the group access rights. This is similar to the following, which means that not a certain four steps are performed and may break at the beginning of the second step.

3. about file Mode Create mask Word (umask)
When each process creates a new file or directory, it requires a file pattern to create the masked word, which is the default permission for the created file or directory. Most users of the system do not handle it, typically by setting the shell's startup file once at logon and then never changing it. Can be viewed directly with the umask command, or directly with Umask 777. Note that this is the shield (U), and if set to 777, then a directory has a permission of D---------。

In general, when designing a program, we always try to use the least privilege (least privilege) model. According to this model, our program should have the minimum privileges necessary to complete a given task, which reduces the likelihood of compromised security.

Third, Process group ID, session group ID, control terminal
Search on the Internet, many are also the concept of apue, I understand that the process group, the concept of conversation group appears to be easy to manage Linux, mainly for the operation control. The most common is to send an interrupt signal (CRTL+C) on the terminal, which is sent to the foreground process group of the control terminal. Simply put, a process group is a collection of one or more processes, and a session is a collection of one or more process groups. Understanding these two concepts has the following points:

1 processes in a process group are usually associated with the same job, can receive signals from the same terminal, each process group has a unique process group ID, each process group can have a leader process, the leader process ID equals the process group ID;

2 A session is a collection of one or more process groups. Typically, the shell's pipeline turns several processes into a group (which is why the processes in the process group are related to the same job).

3 A session can have a control terminal. This is usually a terminal device or a pseudo terminal device that logs on to it.

4 a process group in a session can be divided into a foreground process group (foreground processes group) and one or several background process groups (background processes group).

5 If a session has a control terminal, it has a foreground process group, and the other process group in the session is the background process group.

6 whenever you type a terminal's interrupt key (delete or CTRL + C), the interrupt signal is sent to all processes in the foreground process group.

7 whenever you type a terminal exit key (Ctrl + \), the exit signal is sent to all processes in the foreground process group.

8 The first process of establishing a session with a terminal connection is called a control process.

For this question, or a simple example to illustrate, or on Red Hat, with the Bourne-again shell. The tpgid:id of the
PS of the foreground process group on the TTY (terminal), which is connected to, or-1 if the pro Cess is isn't connected to a TTY.
Run the following command
Ps-o pid,ppid,pgrp,session,tpgid,comm
Output:
  pid  ppid  pgrp  sess tpgid COMMA ND
 3395  3393  3395  3395  3469 bash
 3469  3395  3469  3395  3469 PS
said above Tpgid for the terminal of the foreground process group, in fact, can also be understood as a session of the foreground process group, because a session can have a terminal, if any, should be one by one corresponding relationship. It can be seen on Linux (other operating systems may be different, Linux is supporting the job, if not the job may be different), bash for the background process group, and PS process for the foreground process group (Tpgid can see), and the foreground process group for this session (terminal) has only one process for PS (the foreground process group ID is the process group ID of PS, and PS is the group leader). You can also see that the parent process of the PS process is 3495 and bash, so that bash starts a subprocess with the fork command when it runs a process, replacing the process with the EXEC command.

Ps-o Pid,ppid,pgrp,session,tpgid,comm | Cat
Output:
PID PPID pgrp sess tpgid COMMAND
3395 3393 3395 3395 3501 Bash
3501 3395 3501 3395 3501 PS
3502 3395 3501 3395 3501 Cat
As you can see, the two process PS and cat that are connected by pipes are in a process group (3501), and the foreground process group, and both processes have the parent process of 3395 (bash).

Ps-o Pid,ppid,pgrp,session,tpgid,comm | Cat &
Output First:
[1] 3508
In the output:
PID PPID pgrp sess tpgid COMMAND
3395 3393 3395 3395 3395 Bash
3507 3395 3507 3395 3395 PS
3508 3395 3507 3395 3395 Cat
First out of [1] 3508, for the job number, and then output for the process output, in the click of the space will appear [1]+ done Ps-o Pid,ppid,pgrp,session,tpgid,comm | Cat tips for Job 1 completion. Here's PS and cat for a background process group (3507), Tpgid indicates that the foreground process group is 3395 for the user to log in to bash.

Iv. Tms_utime, Tms_stime, Tms_cutime, Tms_cstime
Note: In the fork process, these time parameters are set to 0.
Any process can invoke the Times function to obtain his own, as well as the wall clock time, user CPU time, and system CPU time for the aborted child process. These concepts have been mentioned in the previous blog (http://blog.csdn.net/ysu108/article/details/7476810) and will not be repeated.  Here is a description of the Times function, which can be illustrated with the Man 2, which is the stores of the "Times" () the "current process" in the "struct TMS" buf points to. The struct TMS is as defined in <SYS/TIMES.H>:
struct TMS {
clock_t Tms_utime; /* User Time * *
clock_t Tms_stime; /* System Time * *
clock_t Tms_cutime; /* User Time of children * *
clock_t Tms_cstime; /* System Time of children * *
};
The Tms_utime field contains the CPU time spent executing instructions of the calling process.  The Tms_stime field contains the CPU time spent in the system while executing tasks on behalf the calling process.  The Tms_cutime field contains the sum of the tms_utime and Tms_cutime values for all waited-for terminated. The Tms_cstime field contains the sum of the tms_stime and Tms_cstime values for all waited-for terminated. All times reported are in clock ticks.

Return VALUE
The Times () returns the number of clock ticks that have elapsed since a arbitrary point in the past.
Note that this structure does not contain any measurements of clock time on the wall, the function returns the wall clock time as its function value, which is measured relative to a certain time in the past, so it cannot be used with its absolute value and must use its relative values. With system command time, you can see directly when the process is running.

V. Signal shielding word, signal set, alarm clock
Note: The unhandled set of semaphores in the subprocess is set to empty, and the unhandled alarm is cleared
1) Signal Concept
The signal provides a way to handle asynchronous events, the event that generates the signal is random to the process, and the process cannot simply test a variable to determine whether a signal has been generated, but must tell the kernel to "do the following when this signal appears", You can ask the kernel to handle one of the following three ways when a signal appears: 1. Ignore this signal, but there are two signals that cannot ignore Sigkill and sigstop, which cannot be ignored because they provide superuser with a reliable way to terminate or stop a process. 2. Capture the signal, in order to do this to inform the kernel to call a user function in the event of a certain signal. 3. Perform the default action, most of the signal default action is to terminate the process.

Each process has a signal screen word (signal mask) that sets the signal set that is currently blocking delivery to the process. For each possible signal, the shield has one corresponding to it. For a signal, if its corresponding bit is set, it is currently blocked. The process can invoke Sigprocmask to detect and change the current signal screen word. The number of semaphores may exceed the number of bits contained in the integer (this use of each bit to represent a feature is quite common in Linux), so POSIX defines a new data type sigset_t, which is used to hold a collection of signals.

2) Signal and process
1. When a program is started, all signal states are system default or ignored, and usually all signals are set to their default actions, unless the EXEC function is invoked, and the EXEC function will be set to the default action of the original to catch the signal, and the state of the other signal is unchanged. For a signal that a process was supposed to capture, when executing a program, nature cannot capture it, because the address of the signal capture function is likely to be meaningless in the new program being executed. A concrete example is when the shell executes a process in the background, the shell automatically sets the process for the interrupt and exit signal to be ignored, so the background process is not affected when the user presses the break key.
2.fork time.
The front is actually foreshadowing, when a process calls fork, its child processes inherit the signal processing of the parent process, because the child processes at the beginning replicate the memory image of the parent process, so the address of the signal capture function is meaningful in the child process.
3.alarm
You can use the alarm function to set up a timer that will time out at a certain point in the future. When the timer times out, the SIGALRM signal is generated. If this signal is not ignored or not captured, its default action is to terminate the process that invokes the alarm function. Each process can have only one alarm clock.

Vi. file Lock (Record Lock)
The function of record locks is that when a process is reading or modifying a part of a file, it can prevent other processes from modifying the same file area (locking). For UNIX systems, the word "record" is misused because the UNIX system kernel does not use the concept of file logging at all. A more appropriate term is a byte-range lock (byte-range locking) because it locks only one area of the file (or possibly the entire file).

Logging locks can not only be modified with more than one process than the same file, but can also create a single process (similar to a singleton pattern) and cannot start two of the same processes. When a process is created, it locks a target file (usually the name of the process) and locks the same file when the second process is created, because the first process is created, the lock fails, and the process exits.

VII. Environment
This section should be the content of the high address portion of the program image when the process is running, along with command-line arguments. There is home (user working directory), PATH, SHELL, user, LOGNAME.

Eight, running status

The Linux process has five states and is also defined in the Sched.h header file
The running state of a process is defined before a file
#define TASK_RUNNING 0 Operational status, equivalent to the execution and readiness status of three states of the process
#define TASK_INTERRUPTIBLE 1 Interrupt wait state. The reason for awakening in this state may be a signal or a timed outage, or i\o ready
#define Task_uninterruptible 2 can not be interrupted waiting state, mainly waiting for i\o
#define Task_zombie 3 Zombie state, the process has ended has released some system resources other than the PCB, waiting for the parent process wait () read the end state
#define TASK_STOPPED 4 Process has stopped
Note: This is a 0.11 kernel that has more than one State in the 1.0 kernel, defined in the sched.h of the 1.0 kernel
#define TASK_SWAPPING 5 Exchange State, the page of the process can also be converted from memory to external memory to space out

Reference:

Apue

Linux kernel 0.11 full annotations