Tom Huckstep converted the HTML version to DocBook.
Sure, you can ls your directory, and grep a file here and there – and you create the process at your shell prompt... And you created the shell prompt when you first logged in...
Ever wonder: So what creates the first process? (If not, you should.) What starts all these processes? Where exactly IS the God of the machine?
If you haven't tinkered with ps yet, now's the time.
$ ps axf |
And to learn about ps, try
$ man ps |
What ps does is show you the current processes that exist – including any ls or grep or find or emacs – many will be idle, as they wait for some signal (a press at the keyboard, a network packet, a signal from the printer). Others will be actively using processor brainpower.
Using ps axf (instead of just plain ps without any arguments) makes it display ALL processes (not just those owned by you, or connected to certain terminals, but ALL processes background or otherwise) in a family-tree format. Here you can see which process spawned which others, for several 'generations'. Here's a trimmed-down cross-section of my system at the moment:
$ ps afx PID TTY STAT TIME COMMAND 5790 ? S 1:41 /usr/sbin/xinetd 25445 ? S 0:00 \_ in.telnetd: wdt 25446 pts/0 S 0:00 \_ -tcsh 25878 pts/0 T 0:00 \_ vi runlevels-intro.wml 26045 pts/0 R 0:00 \_ ps afx |
I edit out lots of extraneous lines to reduce distractions; you'll always see a heck of a lot more than just five lines, in your ps axf output. (By the way -- don't tell anyone I use telnet [a.k.a. Satan's Favorite Evil Bad Security Breach from Hell] even though I've got it locked down via xinetd to interact only with my local intranet. Do as I say, not as I do: use sshd instead!)
The above listing confirmed our initial suspicions about logging in creating the shell, which creates all the other command processes we execute: you can see that xinetd spawned the in.telnetd process, which in turn is the parent process of my tcsh login shell which has two child processes. I am editing this very file (the vi runlevels-intro.wml command) which I suspended (with Ctrl-Z so I could get back to the tcsh command shell) in order to run the ps afx command – so I could cut & paste it into this document.
Below, I run the ps program again, but ask for a LONG listing via ps afxl:
$ ps afxl F UID PID PPID STAT TTY TIME COMMAND 100 0 1 0 S ? 0:17 init [2] 140 0 5790 1 S ? 1:41 /usr/sbin/xinetd 100 101 25445 5790 S ? 0:00 \_ in.telnetd: wdt 100 1000 25446 25445 S pts/0 0:00 \_ -tcsh 000 1000 25878 25446 T pts/0 0:01 \_ vi runlevels.wml 000 1000 26072 25446 R pts/0 0:00 \_ ps axfl |
(Again, I've whittled down on the rows, and this time, the columns, too. Your display will have lots more info than this, guaranteed.) Notice that the process-ID (PID) of tcsh, which is 25446, also shows up as the parent process ID (PPID) for vi and ps ? That's the "family tree" info that's needed in order to display the forest/family-tree style indentation; every running process knows its parent process.
Now -- notice how the PPID (parent) of xinetd is PID #1? That's init, which turns out to be the granddaddy of them all. Quite literally! (ps doesn't display init in the family tree because it's kinda "understood" that everything owes its existence to init.)
Think of init as kinda like Adam in his Garden of Eden, without any worries about sufficient diversity in the gene pool. He just clones himself, and then the clone takes on the function of the requested command process, which may in turn clone itself for the next job, and so on.