This was a good one. I've been working through these for continuing education at work. Some of them are a little boring, just because I already know parts of all this (so that's no criticism - they'd be great for someone not familiar), but this one was on some details I hadn't delved into before. So thanks for a very clear presentation and keep up the great work! Stay safe!
The freaky thing (annoying) about zombies is that they don't or can't trap signals anymore. You find a defunct a.out because your program locked up somewhere, but you can't kill -9 it as it's already marked defunct. It gets even more freaky when the process you were trying to evict was a hung "mount" command, say due to a hung NFS mount point. You get fed up and kill the mount process, but you can't kill it as it's blocked in kernel space, the process disappears, you get your shell back, but the mount command stays as a defunct zombie for a while. Hung NFS mounts are evil.
I think the zombie process definition is not accurate. When a parent dies, its just a running orphan process which will be adopted by init. Zombie is when the child is already dead but it continues to use reasources - and the parent doesnt/canot do anything about it.
At 2.20ish you mentioned that each process will have a pid and this will be a number generated by the system. this number has a limit and then it will be recycled back through the numbers. can you please tell me what is that number (the limit) and also doco relating to that? Thank you. Your content is excellent, please keep going esp with Internals... :)
Thanks for the video. However I believe your description of zombie process is wrong and you actually described an orphaned process. What are your thoughts?
So first, all processes are spawned via a fork call. The "official" UNIX definition is the one I use, even for Linux is: A process which has finished the execution but still has entry in the process table to report to its parent process is known as a zombie process. A child process always first becomes a zombie before being removed from the process table. The parent process reads the exit status of the child process which reaps off the child process entry from the process table.
comment 2 @DJ Do you think you could do a video or so on how a protocol works with its functions on 2 machines(which is ultimately expanded beyond that)? Like when IP sends out to another device- what is the other side wating for or how does it know what to send back like which functions to use? Does that make sense? Or if you are familiar with BGP (and I'm sure you are) how would that work on a 'smile level' (even overly simplified)? Are those functions packed in the same 'while'/'for' loop or are they separate? How does the other device know which function to use to address what it is receiving and then send out (if necessary) and visa-versa? So basically 'how are they 'talking' to each other with knoledge of what they are saying/expecting? DJ, I was saying this for video stuff- not to have you literally writing it all here. I'm sure that would take a while to do Thank you
What happened to Part 1? After noticing that "Linux Internals - SysCalls" was the first in a _series_ of videos, I decided I would make a playlist to "binge-watch" later. I finally stopped procrastinating... creating the playlist, now. I recall seeing "...Part 1: Process Management" prior to today, but I cannot find it.
I bet you were looking for the video at the same time I was creating a playlist for them, the play list is called Linux Internals and should have all of them in there. Cheers
@@CyberGizmo: If only you had acted sooner. I've already created my own playlist. My procrastination could have yielded the pleasant surprise: someone else already took care of this. :-)
@@CyberGizmo: Uhh... it is absent from your playlist, too. I cannot find it by searching your channel. Perhaps you changed the privacy setting on that video?
