When can you close a terminal that has opened a program

[plr4ever]

Hello all,

This question has nagged at me for quite a while now. I've noticed that if you open a program in the terminal, for my usually a virtualization software, and that if it runs long enough, you can close the terminal without kill the program. However, there seems to be a certain amount of time the program must be open in order to not be killed when the terminal is closed.

Sorry if that is unclear, i can rephrase it if need be.

Does anyone know exactly what determines IF/WHEN closing the terminal also kills the process spawned by said terminal?

Thanks
Zach

[coopstah13]

It should always kill the process unless you run it with nohup.

[Rubberman]

Generally, what coopstah13 said. In order to keep a program from receiving a SIGHUP signal when the initiating terminal closes, you need to run the program with nohup. However, a program can catch SIGHUP and ignore it, and that should be fine, provided that stdin, stdout, and stderr have all been redirected to another file descriptor.

[plr4ever]

Alright, your explanations make sense. I think what kept the virtualization program was closing was that the main window i opened via the command line spawned a new window indepenent of the terminal-spawned program.

My apologies, it's late, and that was quite a confusing statement.

[Kieren]

I'm don't think that would make a difference. I'm not 100% on this but I think if window's parent dies then each child's window will die by default unless the program has been told to ignore hang up calls as Rubberman described

Can someone confirm this?

[Rubberman]

I'm don't think that would make a difference. I'm not 100% on this but I think if window's parent dies then each child's window will die by default unless the program has been told to ignore hang up calls as Rubberman described

Can someone confirm this?

The short answer is "It depends"... Generally this is true, but there are situations where the OS will not parent the process to the one that starts it. One example is to start an xterm in the background from another terminal shell. In such a case, the termination of the starting shell won't (AFAIK) kill the xterm.

[Zeroangel]

as a future note, you should always place an ampersand (&) symbol after the command if you want it to run seperately from the terminal.

For example if i'm in a terminal, and I type firefox& -- then it will run independent of the terminal it was launched from.

Other solutions are using 'gksu commandname' (GNOME/GTK) or 'kdesu commandname' (KDE/QT) from the run dialogue (not the terminal) to run a graphical program with root priviliges.

You can also dismiss a program to operate in the background by hitting ctrl+z in the terminal to pause it, and typing bg 1 (or whichever number it is assigned) to resume running the program as a background process from within that terminal. Keep in mind that the program will still be attached to the terminal it is run from, so closing that terminal will kill the process.

[Rubberman]

as a future note, you should always place an ampersand (&) symbol after the command if you want it to run seperately from the terminal.

For example if i'm in a terminal, and I type firefox& -- then it will run independent of the terminal it was launched from.

Other solutions are using 'gksu commandname' (GNOME/GTK) or 'kdesu commandname' (KDE/QT) from the run dialogue (not the terminal) to run a graphical program with root priviliges.

You can also dismiss a program to operate in the background by hitting ctrl+z in the terminal to pause it, and typing bg 1 (or whichever number it is assigned) to resume running the program as a background process from within that terminal. Keep in mind that the program will still be attached to the terminal it is run from, so closing that terminal will kill the process.

As I said, it depends. Some programs like firefox will handle shutting down of the controlling shell (parent process) and/or terminal. Some don't, even if they are run as background processes. Some experimenting will show you how a specific application will behave. In any case, just running a process in the background is no guarantee that they will live beyond the scope of the controlling terminal. Trust me, I have had to deal with a lot of situations where the only viable method to ensure the process continued to completion was to run it in the background with nohup.

[Kernel_Sanders]

Hello all,

This question has nagged at me for quite a while now. I've noticed that if you open a program in the terminal, for my usually a virtualization software, and that if it runs long enough, you can close the terminal without kill the program. However, there seems to be a certain amount of time the program must be open in order to not be killed when the terminal is closed.

Sorry if that is unclear, i can rephrase it if need be.

Does anyone know exactly what determines IF/WHEN closing the terminal also kills the process spawned by said terminal?

Thanks
Zach

You can close it immediately if you use an ampersand ("&").

I.e.,

# xclock &

(Close xterm)

Clock is still running...

.

[Rubberman]

You can close it immediately if you use an ampersand ("&").

I.e.,

# xclock &

(Close xterm)

Clock is still running...

.

That's true of most x-windows applications - they handle the terminal exit properly. However, other processes are not so "forgiving". After all, x-windows apps are designed to work without a controlling terminal. They are a background processes running on a system and send output to the x-server running there, or elsewhere. Non-gui applications on the other hand, are not generally designed to deal with handling the terminal SIGHUP that they will receive, and they WILL terminate. So, just because you run a process in the background with the & does not mean that it will stay around if the controlling terminal shuts down.