Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Linux Process States
Abstract
We'll learn about Linux process states in this article. We'll study each of the five states in which a Linux process can be at different stages in its life cycle. There are five states of a Linux process −
Running & Runnable
Stopped
Uninterruptable Sleep
Zombie
Interruptable Sleep
There is a clear reason for each of the process states which are mentioned above to exist. Having a thorough understanding of these states can be very helpful for debugging issues like resource exhaustion or out-of-control process production. This understanding is much more important if one needs to know how to terminate or kill processes because different techniques may be required based on the process's status.
Running & Runnable
When a new process is initiated, it goes into the running or runnable state. While it is running, the process uses a CPU core to carry out its logic and code. Yet, the thread scheduling approach can force a running process to give up its right to execution. This will ensure that every process has equal access to CPU resources. Since the process is now in a runnable condition and waiting to be executed, it is processed ahead to be added to a run queue in this case.
Running processes are ready to be executed, whereas runnable processes are lined up but, for whatever reason, the CPU is not prepared for scheduling them. As a result, it is scheduled to operate. Virtual CPUs could have a little bit more latency or CPU readiness since actual CPUs in a virtual machine environment are over-provisioned.
Interruptable Sleep
A running process will reach a stage where it is awaiting data at some time. The terminal's input, such as requesting the user's input, could be one way to accomplish this. Other times, the process can be a web server that is sitting idle while it awaits a request.
A well-coded program enters the INTERRUPTABLE SLEEP state as it waits for this. This condition makes it simple and trouble-free to end a process. While it waits for input, the process might enter this state to take a back seat and let other processes use the CPU. Unnecessarily cycling through CPU time would be a waste of resources. The new directories or files can be created by prefixing them with a dot (.) and made hidden from the normal listing of files and directories.
UnInterruptable Sleep
The process is in a waiting state when in UNINTERRUPTABLE SLEEP, just like INTERRUPTABLE SLEEP. Interrupting would often be very problematic in this scenario. Although it is uncommon, a system call, often known as a syscall, is typically to blame when a process is discovered in this state. Mkdir is an excellent example. This state is entered while it is making a syscall to the kernel. Except under extreme conditions, this happens instantly with local discs. This could stall indefinitely in this position with a networked file system like NFS if the correct circumstances were present.
The uninterruptible sleeping state does not respond to any signals; it just waits for the resources to be available before transitioning into a runnable state. The inter-ruptible sleeping state(s), on the other hand, will respond to signals and the availability of resources.
Stopped
You may consider the STOPPED process to be more of a halted process. You can suspend processes using Control + Z in a lot of console tools and apps. The process is stalled and unresponsive in this situation. When a foreground program requests user input but you are not yet prepared to provide it, that illustrates when a process might be in this state. You can Control+Z it and go on to something else. Use the "fg" command to bring it back when you're prepared to continue working on it.
Zombie
Processes in the ZOMBIE state could appear to be in an unusual position. Simply explained, this is the state that a process enters after it terminates but before its parent removes it from the process table. After a process ends, it is the parent's responsibility to "reap" the child's process and tidy up the process table.
In most cases, zombie processes only appear when the parent has not finished this clean up and there is still a running process. The term "zombie" is presumably an analogy since zombies are undead and thus impossible to kill. Consider a method that might function in this circumstance. It has already ended, but it is not yet really gone.
Conclusion
In this tutorial, we learned some examples of how to skip hidden files and directories during recursive copy in Linux. We discussed how to replicate directories recursively in this article while omitting hidden files and directories.
The method of copying everything and then removing hidden items is simple. It could result in security holes and performance issues. Any Linux user can quickly repair this problem. Feel free to attempt any method offered by Linux to solve this issue in order to eliminate this error. The procedures outlined above work with various Linux distributions. All operating systems must have file descriptors as a fundamental element.
934 Views
