Unit - 5
Process Control
The fork () system call will build a new method. The new process consists of a replica of the original process's address space. Fork () produces new processes from current processes. The parent process is referred to as the current process and the process is freshly developed and called the child process. The parent method is used to name the method. The parent and child processes continue to run after the fork () command, whereas the return code for the fork () is zero for the new process, while the child's process identifier is returned to the parent.
System Call Fork () is stored in the library.
System call getpid () returns the current process Process ID, and getppid () returns the parent process Process ID of the current process.
Signals are software interrupts that are transmitted to a program to show that there has been a significant occurrence. Events can range from user requests to errors in memory access that are illegal. Some signs, including the interrupt signal, mean that the software has been requested by a user to do something that is not in the normal control flow.
The following table lists common signals in your programs that you may find and want to use:
5.2.1 List of Signals
Solaris, HP-UX, and Linux differ in the real list of signals.
5.2.2 Default actions
Any signal has a related default operation. The default signal behavior is the action that a script or program executes when a signal is received by it.
Any of the potential default acts are −
5.2.3 Sending signals
A software or script has many means of transmitting signals. For a user to type CONTROL-C or the INTERRUPT key when a script is running, one of the most common ones is.
A SIGINT is sent to the script when you press the Ctrl+C key, which terminates as per the given default action script.
Using the kill button, whose syntax is as follows, is the most typical form for delivering signals.
|
The signal here is either the number or name of the signal to be sent, and the method ID to which the signal should be transmitted is pid. For instance, −
The above command sends to the software running with process ID 1001 the HUP or hang-up signal. Use the following order to give a kill signal to the same mechanism –
This destroys the machine with process ID 1001 running. |
Often the method of parenting is only associated with the case of infant termination. Nginx, PHP-FPM, uWSGI, and others use a worker pool pattern as a popular example. A fixed-size pool of sub-processes must be managed by the main process, while the real payload would be carried out by the processes in the pool. Occasionally, workers die, and in reaction to maintaining the pool size unaltered, the main machine needs to spawn further processes. The Linux kernel includes a family of wait () function calls to await the termination of the child process for this and related scenarios. However, the reporting of the infant exit status back to the parent is enforced because of the way, even careless parents have to specifically await the termination of their offspring. Otherwise, it starts with a zombie apocalypse.
The execution of the generated child process occurs independently when a process forks itself (we will keep process groups and job management out of the reach of this article) and simultaneously with the execution of the parent. While the current process is now a parent of the original process, its execution is not coordinated with it by design. Since the Linux kernel must still have a way to report back to its parent the child exit status (and some utilization stats, such as expended CPU cycles, amount of page faults, etc.), the kernel needs to hold a tiny bit of information even after its exit for any process in machine memory. This data can only be cleaned up after the corresponding parent process has directly read it. From the termination of the process and until the parent has read its status via wait () call, the process remains in a defunct or zombie state. Zombie systems retain consumed device resources, such as memory or process ids, and this inevitably leads to denial of operation.
To substitute the current programme inside a loop with another programme on Unix, one of the exec*( ) family of functions is used. When you execute another programme, the original programme typically continues to run while the new programme is being implemented, resulting in two steps being used to accomplish the desired effect. The exec*( ) functions don't start a new method for you. Instead, you'll need to use fork( ) to get started.
A system call (also known as a syscall) is the programmatic way for a programming programme to order a service from the kernel of the operating system on which it is running. Hardware-related resources (for example, accessing a hard disc drive), the development and execution of new processes, and coordination with core kernel services such as process scheduling are all examples of this. A process's interface with the operating system is provided by system calls.
System calls can only be made from user space processes on most platforms, but on some systems, such as OS/360 and predecessors, privileged system code can also issue system calls.
A Linux process is nothing but an instance of a program running. For starters, you can start a new process when you launch Firefox to search the Internet. In Linux, a unique number is issued to each process named as a process identification number (PID). The Linux kernel makes sure that a specific PID is obtained for each operation. In modern Linux distros, /sbin/init or /lib/systemd/systemd still has a PID of 1 because it is eternally the first operation on a Linux-based system. The ps command is used to list the processes currently operating on Linux and their PIDs.
5.5.1 Linux list processes by user names
The protocol for viewing processes generated by a single Linux user is as follows:
Enable the app or terminal browser
In order to see only the processes owned by a single Linux user, run:
ps -u {USERNAME}
Check for a running Linux process by name:
Pgrep -u {USERNAME} {processName}
Another way to list processes by name is either to run
Top -U {userName} or
Htop -u commands {userName}
In an operating system like Unix or GNU/Linux, the shell is the command interpreter; it is a program that runs other programs. It provides a machine user with an interface to the Unix/GNU Linux framework such that, with any input details, the user may execute various commands or utilities/tools.
It sends an output to the user on the computer, which is the normal output unit, when the shell has finished running a program. It is referred to as the "command interpreter" for this purpose.
5.6.1 Bash Shell
Bash stands for Bourne Again Shell and on many Linux distributions today, it is the default shell. It is also a sh-compatible shell and provides functional programming and immersive use enhancements over sh, which includes:
5.6.2 Tcsh/Csh Shell
Tcsh is an improved C shell that can be used as a command processor for customizable login shells and shell scripts.
The following characteristics are given by Tcsh:
5.6.3 Ksh Shell
Ksh stands for Korn shell, and David G. Korn planned and built it. Just like many other Unix/GNU Linux shells, it is a complete, powerful, high-level programming language and also an interactive command language.
5.6.4 Zsh shell
Zsh is designed to be collaborative and integrates many features such as bash, tcsh, and ksh from other Unix/GNU Linux shells.
Much like the other shells available, it is also a versatile scripting language. Although it has several basic characteristics that include:
5.6.5 Fish
Fish stands for "friendly interactive shell" in its entirety and was published in 2005. Like the other shells, it was designed to be completely immersive and user-friendly, and has some pretty decent features that include:
Init is the parent of all processes executed during the boot of a machine by the kernel. Its key function is to build processes from a script that is stored in the /etc/inittab file. Typically, it has entries that trigger init on each line that users will log in to spawn gettys. It regulates autonomous processes that any individual device needs.
After reading this file, init specifies how the device should be set up at each run level and also sets the default run level. After setting the default run level for the device, Init begins all the background operation.
5.7.1 Run levels
Runlevel, a machine program configuration that enables the life of only a selected set of processes. The processes created for each of these runlevels by init are specified in the file /etc/inittab.
Init will be one of eight runlevels in one of these: 0-6 and S or s. By making a privileged user run telinit, which sends sufficient signals to init, the runlevel may be changed, asking it which runlevel to move to.
5.8 Process Scheduling and Time: Process Scheduling
The scheduler is the kernel component which chooses which process to run next. The scheduler can be viewed as the code that separates the finite processor time resource between the operating processes on a machine (or task scheduler, as it is often called). The scheduler is the cornerstone of a Linux-like multitasking operating system. The scheduler is responsible for the optimal use of the machine when choosing what process should run, and giving the appearance that many processes are operating concurrently.
The framework assigns a lightweight process (LWP) to the process when a process is created. If the procedure is multithreaded, the process could be delegated to more LWPs. An LWP is the entity that the UNIX system scheduler schedules, which decides when processes are operating. The scheduler manages process goals that are focused on parameters of setup, process actions, and requests from users. These priorities are used by the scheduler to decide which process will run next. Real time, device, immersive (IA), fixed-priority (FX), fair-share (FSS), and time-sharing are the six priority groups (TS).
Default scheduling is a policy for time-sharing. To balance the response time of digital systems, this policy automatically changes process goals. In order to balance the throughput of systems that consume a lot of Processor power, the strategy often dynamically changes priorities. The lowest priority is given to the time-sharing class.
In the tms framework that buf refers to, times () stores the actual process times. The tms structure is as described in <sys/times.h>:
The tms utime field includes the Processor time spent running the calling procedure instructions. The tms stime field includes the Processor time expended in the device on behalf of the calling mechanism when performing tasks. For all waited-for terminated children, the tms cutime field includes the sum of the tms utime and tms cutime values. For all waited-for terminated children, the tms cstime field includes the sum of the tms stime and tms cstime values.
When wait (2) or waitpid (2) returns the process ID, times for terminated children (and their descendants) are added in. Times of grandchildren that the children did not wait for are never seen in particular.
Both times recorded are at the ticks of the clock.
5.9.1 Clock
The number of clock ticks that have elapsed from an arbitrary point in the past is returned by times (). This point for Linux 2.4 and earlier is the time the machine was booted. This point is (2^32/HZ) - 300 (i.e., around 429 million) seconds until machine boot time from Linux 2.6 onwards. The return value which overflows with the potential clock t style set. In case of an error, (clock t) -1 is restored, and errno is properly set.
References:
1.. “Unix Concepts and Administration”, Sumitabha Das, TMGH, 3rd Edition.
2. “Unix Shell Programming”, YeshvantKanetkar, BPB Publications.
3. “Unix Utilities”, Tare, MGM.
4. “Advanced Programming in the UNIX Environment”, Stevens and Rego, Pearson Education, 2nd Edition.
