We performed an exhaustive search of all the signals to see what happens with them. This is from sending the signal to the nios process on the compute client, the job that acts as the user's intermediary when submitting an interactive job. It relays signals to the processes running on the exec host. There are 4 categories the signals fall into based on what happens.
1) The bug this issue is about. The interactive connection is terminated, the container continues to run on the exec host, and the res process on the exec host logs the message. I'll note that these are all signals that can get generated from the terminal layer.
checkDriverAuthfork: user <mcallawa> is not in docker group
sigJobLevelDriver: Job failed in lsfExecDriverfork().
2) Signals that seem to work as intended. They're delivered to the processes in the container, res does not log anything, and the appropriate thing happens:
3) Signals where nothing seems to happen at all. I believe these are signals the nios process traps for its own use
4) Signals where the interactive session is terminated, res does NOT log a message, and the container keeps running. I believe these are just signals that nios does not trap and just exits when receiving that signal because it's just the default action for untrapped signals. I wouldn't categorize these as being a bug:
checkDriverAuthfork: user <mcallawa> is not in docker groupsigJobLevelDriver: Job failed in lsfExecDriverfork().