Unix Wonders
Ever wonder about how Linux/Unix processes work?
Last updated
Ever wonder about how Linux/Unix processes work?
Last updated
Unix is a multiuser and multitasking operating system based on POSIX and Single Unix principles, such as one purpose execution, interoperability, and more.
This allows for multiple processors (CPUs) and other system resources. In a multitasking system, each processors can switch between multiple tasks executed in the system without needing to wait for each to finish, avoiding each CPU from executing a single task at a time.
A process is an executing instance of a computer program in memory containing program code and its activity (including services and resources that may be used by the process).
Once a process is executed (prompted by a command, an executable file like a binary, a shell script), all the services and resources that have been initiated remain active for as long as the process is not exited or terminated.
Processes are usually identified by their process identification number (PID), an assigned number raging from 0 to 32767.
Aside from their PID, processes have many other properties, such as the user identification number (UID), the controlling terminal from where the process was launched (TTY), the CPU utilization (C), the start time (S TIME), the CPU time taken by the process (TIME), the command executed that started the process (CMD)…
All running processes in a system can be listed by running the process status command ps, which will output basic properties.
To view more, adding the -f parameter will suffice to view the full output of the process list.
There are different types of processes, daemons, orphans and zombies.
Daemon processes run in the background without a controlling terminal, such as a database or a web server. The first process created on the system is the init process, which is also the most important daemon. By convention, all processes that end with a d are daemons.
Orphan processes are those whose “parent” process has finished or terminated. These processes keep running and eventually “adopted” by the init system process.
Zombie processes are those that have completed execution but remain as entries in the process table. This occurs with child processes, when the parent process has not read the child’s exit status before executing the next task.
Thus, the child process remains in the process table until the parent process reads the child’s exit status and is later eliminated from the process table.
For active proceses to communicate with the resources of the machine, processes need to request them with system calls.
Essentially, system calls are functions that allow processes to comunicate with the kernel (core of the operating system) to use the resources needed for all the services they might need.
All processes must use system calls if they want to get anything done at all
Jax London
There are a wide variety of sytem calls, such as the open(), close(), exec(), write(), read(), lseek(), and select() function, all performing different tasks.
It is rather interesting, that even processes themselves are created with two system calls, fork and exec.
Fork() creates a copy of a process (aka, a child process) that inherits nearly all its properties from the calling (aka, the parent) process except the PID.
Exec() replaces the current process with the new one.
This pattern is all over the place in a Unix system. For example, say you have a terminal open. If you were to call exec nano, where exec refers to the execution of the system call, the terminal will open the editor. However, once you close the editor, both nano and the terminal will close because the use of exec replaced the process of the terminal.
If you were to simply execute nano in a terminal, once you exited the editor you would be back to the terminal because the editor was a copy of the process, not the process itself.
Funnily enough, there is a certain system call named syscall.
This is a library function that saves CPU registers before making a system call, restores those register upon return from the system call and stores any error code returned by the system call if any occurs.
