3

I'm new to Linux and so far,I have come to understand that if we open a new process through a gnome-terminal eg: gedit & "& for running it in background", then if we close the terminal, gedit exits as well. So, to avoid this ,we disown the process from the parent terminal by giving the process id of gedit.

But, I've come across one peculiarity; If we open a gnome-terminal from within a gnome-terminal(parent) with gnome-terminal & and now, if we close the parent terminal, the child terminal doesn't close even if I haven't disowned it.

Why is it? And if there is an exception, what is the reason for making it an exception and where can I find the configuration file(if accessible) where this exception has been mentioned?

5

When you close a GNOME Terminal window, the shell process (or the process of whatever command you instructed Terminal to run) is sent the SIGHUP signal. A process can catch SIGHUP, which means a specified function gets called, and most shells do catch it. Bash will react to a SIGHUP by sending SIGHUP to each of its background processes (except those that have been disowned).

Looking at your example with gedit (with some help from pstree and strace):
When the GNOME Terminal window is closed, gedit is sent SIGHUP by the shell, and since it doesn't catch SIGHUP (and doesn't ignore it), gedit will immediately exit.

─gnome-terminal(31486)─bash(31494)──gedit(31530)

[31486] getpgid(0x7b06) = 31494
[31486] kill(-31494, SIGHUP) = 0
[31494] --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=31486, si_uid=0} ---
[31494] kill(-31530, SIGHUP) = 0
[31530] --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=31494, si_uid=0} ---
[31530] +++ killed by SIGHUP +++
[31494] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=31530, si_status=SIGHUP} ---
[31486] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=31494, si_status=SIGHUP} ---

But when you type the gnome-terminal command and there is an existing GNOME Terminal window, by default GNOME Terminal will do something a bit unusual: it will call the factory org.gnome.Terminal.Factory via D-Bus, and immediately exit; there is no background job for the shell to see for more than a fraction of a second.

As a result of that factory call, the new window you get after typing gnome-terminal is managed by a new thread of the same GNOME Terminal process that is managing your existing window. Your first shell is unaware of the process id of the second shell, and cannot automatically kill it.

─gnome-terminal(9063)─┬─bash(39548)
  │                   └─bash(39651)
  ├─{gnome-terminal}(9068)
  └─{gnome-terminal}(9070)

On the other hand, if you type gnome-terminal --disable-factory &, it won't call the factory, and process-wise it will behave just like gedit did in your example.

─gnome-terminal(39817)──bash(39825)──gnome-terminal(39867)──bash(39874)
  │                                   ├─{gnome-terminal}(39868)
  │
  └─{gnome-terminal}(39819)
Closing the first terminal window will close both the first and the second terminal windows.

1

Running Xfce here but the same probably applies with Gnome terminals.

If I run echo $$ in both terminal windows [EDIT: and then run ps faux] I see only one xfce4-terminal process but two distinct bash processes, which have the same parent: the xfce4-terminal process itself. In fact there is only one terminal process that shows more than one window. Bear in mind that one window doesn't necessarily imply one process. Run ps faux to see it for yourself.

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.