The ^Z binding is not configured in the shell, but in your TTY, the pseudo-device that lets you talk to the physical terminal or, as is typical nowadays, to a terminal emulator program. The TTY carries settings that tell the kernel how to react to keyboard input reported by the device or emulator.
Settings are changed using the stty command:
stty susp "^P"
stty accepts a setting name and its value; in this case the setting name is susp for key that suspends the process, and the value is a key combination, such as ^P. Type stty -a or refer to man stty for a list of available settings.
A process isn't "killed with SIGHUP" -- at least, not in the strict sense of the word. Rather, when the connection is dropped, the terminal's controlling process (in this case, Bash) is sent a hang-up signal*, which is commonly abbreviated the "HUP signal", or just SIGHUP.
Now, when a process receives a signal, it can handle it any way it wants**. The default for most signals (including HUP) is to exit immediately. However, the program is free to ignore the signal instead, or even to run some kind of signal handler function.
Bash chooses the last option. Its HUP signal handler checks to see if the "huponexit" option is true, and if so, sends SIGHUP to each of its child processes. Only once its finished with that does Bash exit.
Likewise, each child process is free to do whatever it wants when it receives the signal: leave it set to the default (i.e. die immediately), ignore it, or run a signal handler.
Nohup only changes the default action for the child process to "ignore". Once the child process is running, however, it's free change its own response to the signal.
This, I think, is why some programs die even though you ran them with nohup:
- Nohup sets the default action to "ignore".
- The program needs to do some kind of cleanup when it exits, so it installs a SIGHUP handler, incidentally overwriting the "ignore" flag.
- When the SIGHUP arrives, the handler runs, cleaning up the program's data files (or whatever needed to be done) and exits the program.
- The user doesn't know or care about the handler or cleanup, and just sees that the program exited despite nohup.
This is where "disown" comes in. A process that's been disowned by Bash is never sent the HUP signal, regardless of the huponexit option. So even if the program sets up its own signal handler, the signal is never actually sent, so the handler never runs. Note, however, that if the program tries to display some text to a user that's logged out, it will cause an I/O error, which could cause the program to exit anyway.
* And, yes, before you ask, the "hang-up" terminology is left over from UNIX's dialup mainframe days.
** Most signals, anyway. SIGKILL, for instance, always causes the program to terminate immediately, period.
Best Answer
When you press Ctrl+z you are sending a SIGTSTP ("terminal stop" signal) to a process currently running in foreground. It causes the process to suspend its operation, however the process still remains in memory.
You can resume a suspended process with
fg(in foreground) orbg(in background) commands.To kill a process you need to send a SIGINT ("interrupt" signal) which you can do by pressing Ctrl+c or a SIGKILL from another process (
kill -s SIGKILL <pid>).They actually are killed and you are seeing a warning message that the suspended processes will be killed when you close the app.