Here is a common definition of a background process:

"A background process is a program that is running without user input. A number of background processes can be running on a multitasking operating system, such as Linux, while the user is interacting with the foreground process Some background processes, such as daemons, for example, never require user input. Others are merely in the background temporarily while the user is busy with the program presently running in the foreground. So that other process can be sleeping and taking up swap space, until activated, which thus makes it currently a background process."

Given that definition, wouldn't that make a process like apache2 a background process since it never interacts with user input in terminal? And wouldn't that consider most process background processes, since most processes running on a system do not deal with user input in the terminal? Oddly enough, I personally wouldn't consider apache2 a background process since a user does interact with it through http requests (just not a terminal).

  • I think there are two definitions here. One is about user input (whether a process can accept user input, such as the terminal). The other is whether a process is sleeping and sitting on swap space or not. Here you can refer to both of these as background processes, which makes the term confusing – JohnMerlino Jul 13 '13 at 22:41

A foreground process does not necessitate user interaction. You can do

cp very_large_file destination

and this would block your terminal until the copy finished and would be considered a foreground process with no user interaction. The point here being whether the process blocks the execution of other processes until it terminates.

Two ways you can make a foreground process into a background one:

1- Adding an ampersand (&) at the end of your command line:

cp very_large_file destination &

2- Stopping a foreground process then bringing it into the background:

cp very_large_file destination



Now apache2 would definitely count as a background process: yes you can interact with it via http requests but it simply listens on port 80 (by default) waiting for such a request: it does not block the system until the user makes a request.

And why do you take issue at most processes being considered background processes? This is indeed normal in a "multi-tasking operating system".

| improve this answer | |
  • Out of curiosity, if I have a program that does block but it is running in a GNU screen session or tmux, and then I leave that screen/tmux session and return control to terminal (but of course they ignore the HUP (hangup) signal so they are still running), would they be considered a background process? I guess you would argue they are foreground processes since within their session, they are blocking, even though they are not blocking in the main terminal. – JohnMerlino Jul 13 '13 at 23:09
  • @JohnMerlino I would say that screen/tmux is the foreground process in this case and when you "return control to a terminal" you send it into the background. – Joseph R. Jul 13 '13 at 23:14

There are two common definitions of “background process”, one in general terms, and one precise and specific to unix.

In a broad sense, you can call “background process” any process that isn't interacting with the user sitting at the console. In this sense, Apache is a background process.

In unix terminology, “background process” has a precise definition. A background process is a process that is started from a terminal but is currently barred from interacting with the terminal. (I'm simplifying by not considering process groups.) You typically get a background process by starting a background job in a shell:

$ myprogram &
[1] 12345

or by starting a program, then suspending it and letting it continue in the background:

$ myprogram
[1]+ Stopped    myprogram
$ bg
[1]+ myprogram &

If you start a program without &, it's in the foreground. There can only be a single process in the foreground in a given terminal at a time. (Or more generally, a single process group, if the foreground process starts some subprocesses.) The shell builtins bg and fg change which process is in the foreground. When a process is in the background, if it tries to read or write to the terminal, it is stopped by a SIGTTIN or SIGTTOUT signal.

I find your intuition that Apache isn't a background process because it's interacting with the user over HTTP strange. Apache is not interacting with the user: it's interacting with a remote web browser (which is interacting with the user) or an automated client (which isn't interacting with the user). If you consider any process that's interacting with an interactive as an interactive process, then any process is interactive, which makes it a useless concept.

The definition you cite conflates background processes with idle processes. There's no reason why a background process would be sleeping or swapped out more than a foreground process. A background process may be doing some heavy computation, for example. Conversely, if the user steps away from the console, and there are other active processes, foreground processes may get swapped out.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.