Rights Management
Unix-like systems are also multi-user. They provide a rights management system that supports separate users and groups; it also allows control over actions based on permissions. The kernel manages data for each process, allowing it to control permissions. Most of the time, a process is identified by the user who started it. That process is only permitted to take those actions available to its owner. For instance, trying to open a file requires the kernel to check the process identity against access permissions (for more details on this particular example, see <xref linkend="sect.rights-management" />).
<primary>user space</primary>
<primary>kernel space</primary>
“User space” refers to the runtime environment of normal (as opposed to kernel) processes. This does not necessarily mean these processes are actually started by users because a standard system normally has several “daemon” (or background) processes running before the user even opens a session. Daemon processes are also considered user-space processes.
When the kernel gets past its initialization phase, it starts the very first process, <command>init</command>. Process #1 alone is very rarely useful by itself, and Unix-like systems run with many additional processes.
First of all, a process can clone itself (this is known as a <emphasis>fork</emphasis>). The kernel allocates a new (but identical) process memory space, and another process to use it. At this time, the only difference between these two processes is their <emphasis>pid</emphasis>. The new process is usually called a child process, and the original process whose <emphasis>pid</emphasis> doesn't change, is called the parent process.
Sometimes, the child process continues to lead its own life independently from its parent, with its own data copied from the parent process. In many cases, though, this child process executes another program. With a few exceptions, its memory is simply replaced by that of the new program, and execution of this new program begins. This is the mechanism used by the init process (with process number 1) to start additional services and execute the whole startup sequence. At some point, one process among <command>init</command>'s offspring starts a graphical interface for users to log in to (the actual sequence of events is described in more details in <xref linkend="sect.system-boot" />).
When a process finishes the task for which it was started, it terminates. The kernel then recovers the memory assigned to this process, and stops giving it slices of running time. The parent process is told about its child process being terminated, which allows a process to wait for the completion of a task it delegated to a child process. This behavior is plainly visible in command-line interpreters (known as <emphasis>shells</emphasis>). When a command is typed into a shell, the prompt only comes back when the execution of the command is over. Most shells allow for running the command in the background, it is a simple matter of adding an <userinput>&amp;</userinput> to the end of the command. The prompt is displayed again right away, which can lead to problems if the command needs to display data of its own.
This translation Translated Debian Handbook/92_short-remedial-course
Following strings have same context and same source.
Translated Debian Handbook/09_unix-services
Translated Debian Handbook/08_basic-configuration




Source Translation
No related strings found in the glossary.

Source information

Source string age
4 years ago
Translation file
zh-CN/​92_short-remedial-course.po, string 128
String priority
Failing checks