Questions about background/foreground running processes

Vexe · 03-04-2013, 05:29 PM

I have an Arch X64 running Awesome WM stand-alone.
I've been reading about processes in Linux. And I came up with some questions, that I couldn't find good answers to.

1- say I ran something at the background: "vlc &"
I can now type whatever commands I want in the shell that I used to start vlc, if I type "exit", the shell is destroyed and vlc will remain alive. BUT if I quit the shell with my Awesome WM quit keyboard shortcut (Ctrl+Shift+C by default), both the shell and vlc die!

Why did vlc die the 2nd time, but didn't in the first time? I think this has to do with the way awesome kills the thing itself, right?

I read about using 'disown %n' where n is the job number. (I also tried typing its name, as in 'disown vlc' it also worked

)
After disowning it, quitting in both ways won't kill vlc.

What's going on?

2- I read that, everytime a user process runs, it MUST get assosiated with a shell (because it's a user process, not a system process, daemon)
But when I run something like, firefox, (not from a terminal, but from a launcher bar, or a globally-set key, via awesome or something) I don't see a shell. And when I "ps -elf | grep firefox" I get a '?' in the tty column. I read that the '?' appears when the process is a system process, or when the process disassociate itself from its shell. I'm assuming it's the 2nd case here. This gives birth to:
A) Can a user process live without a shell?
B) I'm guessing that: firefox first created within a shell, then it forked it self into another shell, and the prvious shell (the one that created it) died, so we don't know the original tty who created it, since it has died. Is this true?

3- What happens actually, when a process is run in the background?
is there a shell associated with it?

I just, can't go on reading a book or something, if logical explanation to details like this is missing.

Thanks a lot in advance for your help

Vexe · 03-04-2013, 05:32 PM

I just worked out something that adds more credibility to my 2nd point, here's what I did:
in a terminal: "vlc &" checked out its tty, it was 'pts/3' and then "exit" the shell I ran vlc from. opened up another terminal, did a
"ps -fle | grep vlc" looked at the tty column, and guess what, it was '?'

So, is this like a slow motion to what actually happened?

theKbStockpiler · 03-04-2013, 07:35 PM

Quote:

2- I read that, everytime a user process runs, it MUST get associated with a shell (because it's a user process, not a system process, daemon)

I believe this is only true if not using a GUI. If you are using a GUI bash is not involved,no shell. A background process as far as BASH is concerned is a way to be able to keep using BASH while a different process is running otherwise the terminal is occupied until the process is finished.

The shell term is not very well understood. BASH is a interpreter that executes commands that are kept in a separate library from what I understand. Commands are small separate applications that BASH coordinates with other commands. A shell is a method to interact with the operating system. A desktop environment is like a shell. The kernel compared to an onion is a bunch of garbage if that is where you are getting the info from in my opinion .http://www.linux-tutorial.info/modul...ntent&pageid=5 This guide while well meaning is too terse to be much good.Read it last.

Some Commands that BASH executes are not killed when the ("shell" invocation of BASH) is closed. BASH is not the only interpreter that can be used as a shell. There are a few others.

If this reply was useful please move my reputation mark off of 49. I'm sick of looking at it.Thanks!

theKbStockpiler · 03-05-2013, 06:40 PM

http://www.dummies.com/how-to/conten...Id-323072.html I'm not suggesting you buy the book but this supports my post.

suicidaleggroll · 03-05-2013, 07:55 PM

1 - vlc is still running in that shell, it's just in the background. Typing exit tells the shell that you want to close, but it won't actually close until all background processes have stopped. If you force quit it, all foreground and background processes will be killed along with it. This all becomes VERY clear if you ssh into a machine and repeat your experiment. You can launch something in the background on the remote machine, then type exit. What happens? The screen goes black, ssh is sitting there waiting for the background process to exit so that it can return you back to your own machine. If you kill the ssh connection (close the terminal, type ~. or whatever, then the background process will also be killed).

2a - Processes don't need a shell. Of course if you start the process from a shell, and then subsequently kill the shell while the process is still running, you'll kill the process as well, but there are ways around that. For example, processes started through cron have no shell, they're just running in the background dumping output to a service that mails the user when the process is finished. Alternatively, you can start a process using "nohup" to TRULY fork it to the background and disassociate it from your shell. If you do that, you can do whatever you want with your shell, keep running things, type exit, kill it, it doesn't matter. Perhaps it's best to think of running a command with a trailing "&" like you're not really running it in the background, you're just separating it's I/O from your terminal. It's still running in your shell, it's just not writing to it, and things you type aren't being written to it.

2b - There probably was no tty for firefox, same as if a command is started from cron.

chrism01 · 03-05-2013, 09:58 PM

Quote:

running a command with a trailing "&" like you're not really running it in the background, you're just separating it's I/O from your terminal.

Actually it still outputs to terminal eg

Code:

 ./t.sh &
[1] 10852
[lq]$ 1:10
2:11
3:12
4:13
5:14
6:15
7:16
8:17
9:18
10:19
11:20

It hangs on the last o/p until I hit <Enter>, then I get

Code:

[1]+  Done                    ./t.sh

Code was

Code:

for (( x=1,i=10 ; x <= 10, i<=20; x++, i++))
do 
	echo "$x:$i"
done

suicidaleggroll · 03-06-2013, 08:06 AM

Quote:

Originally Posted by chrism01

Actually it still outputs to terminal

Good point. I suppose it's just separating the input from the terminal then, not the output.

sundialsvcs · 03-06-2013, 08:24 AM

Okay, now here's the answer you're looking for ...

If you launch a background command (sometimes called a "job"), it is owned by your current bash-shell. You can switch which one has input focus.

If you want a command to survive your logoff, use "nohup." It may or may not do so.

All user commands are owned by some shell. Your GUI session is a shell. Shells can be nested, as all processes can.

The CPU will always try to run at 100% utilization. "Background" vs. "Foreground" sets the dispatching-priority, which is one of several variables used to choose which process or thread to run next on a particular CPU.

CPU-intensive work actually runs better at lower priority because it likes long, uninterrupted slots of time but can readily afford to give them up. I/O-intensive work (and GUIs) need quick response. By running CPU-intensive work with "nice," you help the scheduler make good choices for the work.