The basic explanation of how Bash handles SIGUP is (in 5.1): 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.
Bash doesn't execute .bash_logout in this situation, although that isn't made entirely clear: When an interactive login shell exits, or a non-interactive login shell executes the exit builtin command, bash reads and executes commands from the files ~/.bash_logout and /etc/bash.bash_logout, if the files exists. However, if I set a trap on SIGHUP, Bash's behavior seems to change. In particular, if I set a no-op trap: trap ':' SIGHUP then .bash_logout *is* run during the processing of the HUP. I have not tested to see when SIGHUP is resent to child jobs. The documentation suggests that SIGHUP is resent if Bash exits on SIGHUP, but if Bash exits normally, SIGHUP is sent only if huponexit is set, and huponexit seems to be unset by default. But it's possible that behavior interacts with trap as well. It seems to me that the documentation needs to be tweaked to explain how trap of SIGHUP interacts with the default SIGHUP processing. Dale