Commands in the background are terminated after closing the terminal

Using the & symbol backgrounds the task in that shell session. Even though they are backgrounded, they are still connected to the shell and will die when you kill the shell.

Doesn't this happen in other versions of ubuntu?

This never happened some months ago. I could start git gui in the background and close the terminal without a problem (I do this because there is no start menu entry for git gui). But after some time git gui was closed too if I closed the terminal. Now after some months I reinstalled Ubuntu 11.04 and upgraded to Ubuntu 11.10 dev. But the bug is still present.

Hi, I can confirm the original report.

Steps to reproduce (on an 11.10 system, daily image from 20110802.1)

1- Start the terminal (gnome-terminal)
2- Launch for example gedit &
3- Close the terminal

Expected behavior:
- The gedit instance that was launched through the terminal remains

Actual behavior:
- gedit also dies when closing the terminal

However this only happens with gnome-terminal and only on 11.10:

- Doing the same on 11.04 with gnome-terminal works as expected, the gedit window remains once the terminal is closed
- Doing the same on 11.10 with xterm (use the Unity application finder to get the xterm) works as expected, the gedit window remains once xterm is closed.

I did find a workaround (back to my old Unix command line tricks), which is using nohup to launch gedit as "immune to hangups and output to a non-tty", in gnome-terminal do:

nohup gedit &

This should also work for other GUI programs.

The same problem appears in LXTerminal too. Maybe a shared component is affected by this problem.

I'm running 11.10 with all updates and I'm unable to reproduce this behavior anymore. I'll mark the bug as Fix Released (fixed by an unknown upgrade).

If you're still experiencing this problem, please make sure to fully upgrade your system and try again; if it still happens, please provide detailed steps to reproduce (I run gedit & in the reported terminal programs) and mark it as New again.

Thanks!

My system was already fully upgraded in the previous post to Ubuntu 12.04 dev. The lxterminal version is 0.1.11-0ubuntu1. I'm starting LXTerminal over the startmenu from lxpanel, typing "git gui &" in it and pressing enter. After git gui ist started I'm closing lxterminal by clicking on the x in the window. LXTerminal and git gui are now closed.

Hi Sworddragon,

Thanks for testing this!

Could you confirm whether this happens in other programs? I tested mainly using gedit and gitg and I am able to leave them running even after the terminal closes. This is using lxterminal and gnome-terminal.

git gui invokes, I think, gitk, which is written using the tcl/tk toolkit, so maybe the problem doesn't happen anymore for gtk applications such as gedit, but does for tk applications. This test will help confirm that and decide what to do about this.

Thanks again!

I have tested this now with lxterminal and gedit but the problem still exists. I have tried xterm too but the problem appears here too.

is there anything on ~/.xsession-errors ? I cannto reproduce this issue, could you please attach that file to the reporT? thanks.

lxpanel is throwing a BadWindow on these steps. Maybe it has something to do with this.

I have Ubuntu 10.04 (should be up-to-date) and this is what happens with gnome-terminal:

1. gedit
2. Close terminal with the close button on the title bar (or close the corresponding tab).
-> A dialog opens saying "Close this terminal? There is still a process running in this terminal. Closing the terminal will kill it." Both "Cancel" and "Close Terminal" buttons work as expected.

1. gedit &
2. exit
-> Terminal (or the corresponding tab) closes but gedit keeps running.

1. gedit &
2. Close terminal with the close button on the title bar (or close the corresponding tab).
-> Both terminal and gedit die without any warning or question. Any unsaved data will be lost.

I used gedit as an example, but it seems that same things happen with other programs, too (I tested with e.g. emacs, firefox, kile and xdvi).

Comment #1 is correct. This is the intended behaviour of the system.

When you start a process it is always as a child of another, usually some session. Graphically, you log in to a desktop session. When you start gnome-terminal you are beginning a separate shell session and any programs started in that terminal belong to the shell session [1]. There are good reasons for this design.

Any program can be started in the desktop session, without needing a menu entry. For example, GNOME provides the run program dialog (ALT-F2) for this purpose. If you desire a program to last for the duration of the desktop session, start it using the run dialog and *not* from gnome-terminal.

[1] Some programs apparently take measures to escape from the shell session so that they appear to run in the desktop-session. These are exceptional and should not be considered the norm. If you start a program from a shell session you should expect that it will remain under the control of that shell.

> The same problem appears in LXTerminal too. Maybe a
> shared component is affected by this problem.

FYI the shared component in this case is the shell (usually /usr/bin/bash or similar) which is run by these terminal programs.

Processes started by a shell are (typically) terminated when that shell exits. That is by design.

Bug #376147 tracks the issue of gnome-terminal not warning that closing the terminal will terminate background processes.

Are you sure that this is the correct behavior? Some time before I have opened this ticket it worked like expected: If I have started an application in the background I could close the terminal without closing the application. The only explanation would be that another process become the new parent (maybe init). At least the BadWindow error doesn't appear anymore. But a workaround is to use nohup which will still keep the application open.

On 20 September 2012 18:29, Sworddragon <email address hidden> wrote:
> Are you sure that this is the correct behavior?

Yes.

> Some time before I have
> opened this ticket it worked like expected: If I have started an
> application in the background I could close the terminal without closing
> the application.

Some programs take special measures for this; most do not. You should
not expect any process started from a specific shell to survive after
you exit that shell. If you want to start an arbitrary program, use
the run dialog (ALT-F2) – this is what it's for.

> The only explanation would be that another process
> become the new parent (maybe init).

Not init (exit from the desktop session and see that the program in
question is closed).

> If you want to start an arbitrary program, use the run dialog (ALT-F2) – this is what it's for.

I have never thought to use this but it is a good idea.

> Not init (exit from the desktop session and see that the program in question is closed).

I don't know it but with nohup the process will be a direct child of init after closing the terminal. But at least I have now some ways to solve this problem and with the BadWindow message fixed here is nothing more to do.

On 20 September 2012 19:17, Sworddragon <email address hidden> wrote:
> I don't know it but with nohup the process will be a direct child of
> init after closing the terminal.

If so then do not use nohup for this purpose.

> If so then do not use nohup for this purpose.

Is there a special reason? For example I'm opening htop to watch the process list and after this I'm opening a new terminal and executing "nohup scite > /dev/null 2>&1 &" in it:

| /sbin/init
|- x-terminal-emulator -e htop
|-- /bin/bash
|--- scite
| ...

After closing the terminal:

| /sbin/init
|- scite
| ...

Calling scite directly with Alt+F2:

| /sbin/init
|- scite
| ...

So there is no difference for me.

On 20 September 2012 19:48, Sworddragon <email address hidden> wrote:
> So there is no difference for me.

My mistake then.