27

I was just wondering, for instance when I launch qtox with:

qtox &

And then close Terminal, qtox closes with it. However when running etherape using:

sudo etherape &

Closing Terminal doesn't close or cause any problem to Etherape. And among different applications there is different behaviour, some close when Terminal does, others do not, how come? Why do some close when others don't? I am running Ubuntu GNOME 15.10 with GNOME 3.18.

kos
  • 35,535
  • 13
  • 101
  • 151
  • 1
    Could it be that you open a terminal, you run qtox, you close terminal, all you !! But the second goes you open terminal, sudo runs etherape, now you close your terminal, but sudo keeps running till sudo closes? – Ken Mollerup Nov 30 '15 at 16:42
  • Well, if you don't want `qtox` exiting when you close the terminal you can always run it with `nohup qtox &`. – Terrance Nov 30 '15 at 17:06
  • @Terrance: Well, in this question I was specifically asking why, not how... That would be [my other question](https://askubuntu.com/questions/704322/how-to-keep-programs-running-that-are-executed-using-and-close-when-terminal)... :) –  Nov 30 '15 at 17:08
  • 1
    @ParanoidPanda Ah, good point. My bad. =) – Terrance Nov 30 '15 at 17:09

1 Answers1

36

When you close a terminal the terminal sends a SIGHUP signal to the shell; the shell, in turn, sends a SIGHUP signal to all its children process groups, which include backgrounded process groups;

How each single process will react to the signal is entirely up to the process: if the process didn't define a handler for the signal and tell the kernel (via some syscall such as signal() or sigaction()) that it wishes to handle it, the kernel executes the default handler for the signal, which in case of a SIGHUP signal consists in terminating the process.

However, when you run a command with sudo, the UID of the sudo process and its child process is set to 0 (root); in general, unless the UID of the process sending the signal is 0 (root) or the same as the target process, the kernel dismisses the signal (i.e.: a process can't send signals to a process owned by another user, unless the process sending the signal is owned by root); that's why an user-run process such as the Bash instance run by the terminal can't SIGHUP a sudo process and, ultimately, closing a terminal doesn't affect a process started with sudo.

kos
  • 35,535
  • 13
  • 101
  • 151
  • 7
    And that's why we need `nohup` in front of those commands that do close with SIGHUP :) Upgoated – Sergiy Kolodyazhnyy Nov 30 '15 at 19:00
  • 9
    I *think* there's nothing magic about `sudo`. `sudo` just runs command as another user and you can't send signal to other users' processes. See `man 2 kill`. – el.pescado - нет войне Nov 30 '15 at 19:15
  • @el.pescado So is `sudo` some kind of poor man's `nohup`? – Hagen von Eitzen Nov 30 '15 at 19:20
  • @el.pescado Indeed. My answer was edited by OP as he realized he ran the command using sudo, it was different before; I clarified that point. – kos Nov 30 '15 at 19:35
  • 7
    @HagenvonEitzen If you want, but I'd highly refrain from running a command that doesn't require `sudo` with `sudo` for its `nohup` side-effect, considered all the other downsides. – kos Nov 30 '15 at 19:47
  • 2
    @Serg we don't need `nohup`, it creates unneeded `nohup.out` files after it. Rather use `disown` builtin command. – Ruslan Dec 01 '15 at 11:32
  • @Ruslan If one redirects output streams to `/dev/null` , nohup won't create the `nohup.out` file. Example: http://paste.ubuntu.com/13602644/ There is always a solution – Sergiy Kolodyazhnyy Dec 01 '15 at 17:33
  • @Serg of course it's a solution, just more to type ;) – Ruslan Dec 02 '15 at 04:32