When you start a system, the first process started is INIT, which gets the PID of 1. Afterwards, all other processes are child of INIT (PID: 1) and each of them can have child processes and so on.
My question is, how are processes related when it comes to memory and cpu ? I am aware that each process can have multiple threads and that it each process has its own heap. In that case, how are parent and child processes related when it comes to resources ?
If, for example a process has a limit on the CPU amount it can use and that limit is set by the cgroup the process it's in, how would that affect child processes ? Does the CPU-amount of the parent process increase as the CPU-amount of its child processes increase ?
Related
When you set a cpu limitation for a process and that process creates several other child processes, as the child processes increase their CPU-shares, do the CPU-shares of the parent process increase as well ?
The same question would go for memory. Although, memory is different as far as I am concerned since I've learned that each process has its own heap. Would it then be correct to say that the memory limitation of a process isn't influenced by the amount of memory its child processes use ?
I read that PID reuse is done when process is zombie and was waited for.
What happens if I forked hundreds of processes and just killed the parent without waiting for them? I know they will be children of init process but who will call wait on them? (else we are in trouble and limited with PIDs).
I know they will be children of init process but who will call wait on them?
init (process with PID 1) will reap all of its child processes, including adpoted zombie processes. As it says on https://en.wikipedia.org/wiki/Zombie_process
init periodically executes the wait system call to reap any zombies
with init as parent.
I'm a beginner in Operating Systems and Linux, just a question on zombie processes.
I don't understand why parent processes need to reap child processes? Can't Linux just be designed to behave like: whenever a child process is terminated, it is going to be reaped automatically immediately without waiting for its parent process, which can save programers' time? Another question is, why a zombie process still consume system memory resources, isn't that it is already terminated, nothing needs to be maintained?
I have a process on Linux that starts up 20 child processes via fork. When I kill the parent process, it will often kill all of the child processes, but sometimes it doesn't kill all of them, and I'm left with some orphaned processes. This isn't a race condition on startup, this is after the processes have been active for several minutes.
What sort of things could cause SIGTERM to not propagate to some child processes properly?
There is no automatic propagation of signals (SIGTERM or otherwise) to children in the process tree.
Inasmuch as killing a parent process can be observed to cause some children to exit, this is due to ancillary effects -- such as SIGPIPEs being caused when the child attempts to read or write to a pipeline with the dead parent on the other side.
If you want to ensure that children are cleaned up when your process receives a SIGTERM, install a signal handler and do it yourself.
If you use process group id (pgid) when sending a signal, the signal would be propagated to parent process and all its children.
To know pgid, use ps a -o pgid,command.
Wikipedia basically gives all the possible information about zombie processes that I NEED to know but just a simple line on how it might be useful..in that a conflict in PIDs will not exist in the event the parent process creates another child process.
How is this then actually "useful"? Wouldn't the PID be then available if the named zombie process were to be removed instead of being kept there?
Or are there any other reasons as to why the zombie process should exist?
Zombie processes are actually really important and definitely need to exist. First it's important to understand how process creation works in Unix/Linux. The only way to create a new process is for an existing process to create a new child process via fork(). In this way, all of the processes on the system are arranged in a nice orderly tree heirarchy. Try running ps -Hu <your username> on a Linux system to see the heirarchy of processes that you own.
In many programs it is critically important for a parent process to be able to obtain basic information about its child processes that have exited. This basic information includes the exit status and resource usage of the child. When the parent is ready to get information about a dead child process it calls one of the wait() functions to wait for a child to exit and obtain exit status and resource usage info.
But what happens if a child process exits before the parent waits for it? This is where zombie processes become necessary. The operating system can't just discard the child process; the operation of the parent process may be dependent upon knowing the exit status or resource usage of the child. i.e. The parent process might need to know that the child exited abnormally, or it might be collecting CPU usage statistics for its children, etc. So, the only choice is to save off that information and make it available to the parent when it finally does call wait(). This information is what a zombie process is and it's a critical part of how process management works on Unix/Linux. Zombie processes allow the parent to be guaranteed to be able to retreive exit status, accounting information, and process id for child processes, regardless of whether the parent calls wait() before or after the child process exits.
This is why a zombie process is necessary.
Footnote: If the parent process never calls wait(), then the child process is reparented to the init process when the parent process dies, and init will wait() for the child.
The answer is on Wikipedia as well, which is:
This entry is still needed to allow the parent process to read its
child's exit status.
Zombie processes are useful.
Zombie processes allow the parent to be guaranteed to be able to retrieve exit status, accounting information, and process id of the child processes.
A process that doesn't clean up its child zombies isn't programmed properly.