The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.

That's a stupid default, but my guts tell me it's a RH fault rather than bash. Btw, with zsh you can use &! as a shortcut to disown, and processes forked with & do get sighup.
–
Jürgen StrobelSep 19 '11 at 13:05

When you fork a process into the background it will still be the child process from the shell executing it.

All child processes running under a shell are sent a SIGHUP upon exit. Performance varies slightly depending upon the exact situation, which is detailed verbosely in bash's manpage. Other shells likely have similar descriptions.

Apache, and other daemons, typically reload configuration on SIGHUP. Userspace utilities often die. Application performance linked to signals can be unique to the application.