-   Linux - Newbie (
-   -   Jobs verse Processes (

NotionCommotion 04-10-2014 01:25 PM

Jobs verse Processes
I see how "jobs" will give me a list of jobs running along with their job number. I can fg, bg, or kill them by using % before the job number.

Each one of these jobs also has a process identification. It appears I can kill a process using this identification (without the %), but cannot do bg or fg.
  • Does the above look accurate? How else are jobs and processes related?
  • Is there any way to compare job numbers to process IDs?
  • I understand that all jobs are processes, but not all processes are jobs. What other type of processes are there other than jobs and daemons?

Thank you

rtmistler 04-10-2014 03:23 PM

In a nutshell, jobs lists the processes known or run from the shell which you are typing in at the time.

If you open a new command shell and don't execute any jobs, you'll likely see no jobs.

The ps command shows processes and will show the shell process you are in as well as the ps you executed, by default. You can add arguments to see all processes for yourself or other users. The process ID in both is the actual process ID handle assigned by the system.

If you look at the /proc directory, you will see sub-directories matching all the processes in your system.

Everything in Linux is coupled to files. Down in those directories, you'll see information about the process, the file handles open, and other useful/interesting stuff.

If you use

jobs -l
you'll see the process ID of the running jobs known to your current shell. Other variations will show jobs which are paused or sleeping versus ones which are running. This is the same information which you'll see in the ps command. The number you see shown for a job, not [1], but something like this:

[1]+  3072 Running                emacs &
the 3072 is the process ID for my emacs session and as you can see, it is in a running state.

To see all processes known to the system, use "ps -ef". Harder to describe whether something is a daemon versus not. A convention is that the name or many daemons ends with a "d", so if I were to write a "main daemon" I may choose to call it "maind"; however I write some daemons for embedded systems and I don't care about conventions, I know my process names, and therefore if I have a main program named "charlie" and I have it so that it becomes a daemon when run, the name of that process and any children will be "charlie", but that's my business in a closed architecture.

I wrote a blog entry about daemons which is pretty involved and there's a further link in there which is one of the sources for information about this. Feel free to peruse that, it is here.

NotionCommotion 04-11-2014 10:03 AM

Thank you rtmistler,

Both your reply to my question, and your referenced blog were very helpful.

All times are GMT -5. The time now is 06:36 AM.